From: "Darrick J. Wong" <djwong@kernel.org>
To: Luca Di Maio <luca.dimaio1@gmail.com>
Cc: linux-xfs@vger.kernel.org, dimitri.ledkov@chainguard.dev,
smoser@chainguard.dev
Subject: Re: [PATCH RFC 0/2] prototype: improve timestamp handling
Date: Mon, 21 Apr 2025 20:10:19 -0700 [thread overview]
Message-ID: <20250422031019.GM25659@frogsfrogsfrogs> (raw)
In-Reply-To: <20250416144400.940532-1-luca.dimaio1@gmail.com>
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
>
next prev parent reply other threads:[~2025-04-22 3:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-16 14:43 [PATCH RFC 0/2] prototype: improve timestamp handling Luca Di Maio
2025-04-16 14:43 ` [PATCH RFC 1/2] xfs_proto: add origin also for directories, chardevs and symlinks Luca Di Maio
2025-04-16 16:07 ` Darrick J. Wong
2025-04-16 14:43 ` [PATCH RFC 2/2] proto: read origin also for directories, chardevs and symlinks. copy timestamps from origin Luca Di Maio
2025-04-16 16:07 ` Darrick J. Wong
2025-04-17 14:14 ` Luca Di Maio
2025-04-22 3:10 ` Darrick J. Wong [this message]
2025-04-22 6:16 ` [PATCH RFC 0/2] prototype: improve timestamp handling Luca Di Maio
2025-04-23 14:46 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250422031019.GM25659@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=dimitri.ledkov@chainguard.dev \
--cc=linux-xfs@vger.kernel.org \
--cc=luca.dimaio1@gmail.com \
--cc=smoser@chainguard.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox