Re: [PATCH RFC 0/2] prototype: improve timestamp handling

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Apr 22, 2025 at 08:16:17AM +0200, Luca Di Maio wrote:
> Thanks Darrick for the feedback,
> I've also sent a v3 patch for this that still uses the prototype file,
> without changing the file specification at all.
> Let me know what you think of that.

TBH I'm not enthusiastic about changing the protofile parsing at all.
The file format is creaky but stable; let's not spend engineer time on
propping up old designs...

> I'm also a bit more aligned on the "walk and copy" functionality, I'll
> try to implement that too. In the meantime if the prototype file
> implementation works, it could also be an improvement what do you
> think?

...because I like this idea a lot better.

--D

> Thanks for your review
> L.
> 
> On April 22, 2025 5:10:19 AM GMT+02:00, "Darrick J. Wong" <djwong@kernel.org> wrote:
> >Crumbs, apparently I forgot ever to send this message. :(
> >
> >On Wed, Apr 16, 2025 at 04:43:31PM +0200, Luca Di Maio wrote:
> >> Hi all,
> >> 
> >> This is an initial prototype to improve XFS's prototype file
> >> functionality in scenarios where FS reproducibility is important.
> >> 
> >> Currently, when populating a filesystem with a prototype file, all generated inodes
> >> receive timestamps set to the creation time rather than preserving timestamps from
> >> their source files.
> >> 
> >> This patchset extends the protofile handling to preserve original timestamps (atime,
> >> mtime, ctime) across all inode types. The implementation is split into two parts:
> >> 
> >> - First patch extends xfs_protofile.in to track origin path references for directories,
> >> character devices and symlinks, similar to what's already implemented for regular files.
> >> 
> >> - Second patch leverages these references to read timestamp metadata from source files
> >> and populate it into the newly created inodes during filesystem creation.
> >> 
> >> At the moment, the new `xfs_protofile` generates a file that results
> >> invalid for older `mkfs.xfs` implementations. Also this new implementation
> >> is not compatible with older prototype files.
> >> 
> >> I can imagine that new protofiles not working with older `mkfs.xfs`
> >> might not be a problem, but what about backward compatibility?
> >> I didn't find references on prototype file compatibility, is a change
> >> like this unwanted?
> >
> >I think it'd be more ergonomic for mkfs users to introduce an alternate
> >implementation that uses nftw() to copy whole directory trees (like
> >mke2fs -d does) instead of revising a 52-year old file format to support
> >copying attrs of non-regular files.  Then we can move people to a
> >mechanism that doesn't require cli options for supporting spaces in
> >filenames and whatnot.
> >
> >--D
> >
> >> If so, what do you think of a versioned support for prototype files?
> >> I was thinking something on the lines of:
> >> 
> >> - xfs_protofile
> >>   - if the new flag:
> >>     - set the first comment accordingly
> >>     - add the additional information
> >>   - else act as old one
> >> 
> >> - proto.c
> >>   - check if the doc starts with the comment `:origin-files enabled`
> >> 	(for example)
> >>   - if so, this is the new format
> >>   - else old format
> >> 
> >> Eager to know your thoughts and ideas
> >> Thanks
> >> L.
> >> 
> >> Luca Di Maio (2):
> >>   xfs_proto: add origin also for directories, chardevs and symlinks
> >>   proto: read origin also for directories, chardevs and symlinks. copy
> >>     timestamps from origin.
> >> 
> >>  mkfs/proto.c          | 49 +++++++++++++++++++++++++++++++++++++++++++
> >>  mkfs/xfs_protofile.in | 12 +++++------
> >>  2 files changed, 55 insertions(+), 6 deletions(-)
> >> 
> >> --
> >> 2.49.0
> >> 
>