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

[Luca Di Maio <luca.dimaio1@gmail.com>]

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.

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?

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