public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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
> 

  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