On Wed, 2 Mar 2022, Linus Torvalds wrote:
> On Mon, Feb 28, 2022 at 12:43 AM Xavier Roche <[email protected]> wrote:
> >
> > Various filesystems (including ext4) now support file creation time.
> > This patch adds such support for tmpfs-based filesystems.
Please ignore this patch for now: I presume Xavier did not understand
the "from akpm to Linus in next merge window" flow, and thought he had
to resend the patch to you.
>
> What's the odd huge-page noise in this patch?
That was one of the fixups I added, which akpm is holding in a -fix
patch to be merged in, and maybe he'll include my comment from it:
3. Using shmem_getattr() on other file types than regular requires that
shmem_is_huge() check type, to stop incorrect HPAGE_PMD_SIZE blksize.
(shmem_getattr() was only on regular files before: Xavier's patch
added it to directories etc, to provide btime for them too; but
shmem_getattr() can also include a dubious adjustment to blksize.)
>
> Other oddities:
>
> Reply-To: [email protected]
>
> WHAT?
No comment from me.
>
> And finally - if we really want to treat btime as a first-class entity
> and expect things like tmpfs to support it, then we should just bite
> the bullet and put it in 'struct inode' along with the other times.
I've no objection if someone does that later. I've no investment
in btime myself (my instinctive reaction was, is this thing worth
another 16 bytes of inode space?), but Xavier thought it worth doing,
and Andrew worth taking, so go with the flow.
Ah, Andrew has replied meanwhile, I hope I'm not contradicting!
Hugh
On Wed, Mar 02, 2022 at 12:17:30PM -0800, Hugh Dickins wrote:
> Please ignore this patch for now: I presume Xavier did not understand
> the "from akpm to Linus in next merge window" flow, and thought he had
> to resend the patch to you.
I will resend a fixed v4 version in a moment, sorry for the noise (and
I indeed did not fully understand the flow).
> > And finally - if we really want to treat btime as a first-class entity
> > and expect things like tmpfs to support it, then we should just bite
> > the bullet and put it in 'struct inode' along with the other times.
> I've no objection if someone does that later.
I might give it a try if this is something that can be of interest.
The idea of having btime in 'struct inode' would make the btime a
first-class citizen, allowing to have more consistent (w.r.t filesystem
types) behavior.
This would also mean allowing to _change_ it, typically to allow archivers
to set the creation time as they do for {a,c,m}time.
Currently, birth time semantic is bound to the current filesystem's
life cycle and as such is irrelevant after a restore, or a 'tar xf'.
The only gray area to me is whether or not we "can" always change this
property without unforeseen consequences, typically for ext4.