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@xxxxxxxxxx> 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 > >> >
