Linux filesystem development
 help / color / mirror / Atom feed
From: "koraynilay" <koray.fra@gmail.com>
To: "Pedro Falcato" <pfalcato@suse.de>, "koraynilay" <koray.fra@gmail.com>
Cc: "David Sterba" <dsterba@suse.com>,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	"Christian Brauner" <brauner@kernel.org>,
	"Chris Mason" <mason@kernel.org>, "Jan Kara" <jack@suse.cz>,
	"Darrick J . Wong" <djwong@kernel.org>,
	"Sean Smith" <defendthedisabled@gmail.com>,
	"Andrey Albershteyn" <aalbersh@kernel.org>,
	<linux-btrfs@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v2 1/2] vfs: add provenance time (ptime)
Date: Wed, 28 Oct 2026 22:12:24 +0100	[thread overview]
Message-ID: <DMGS4KQLY24Q.14MUTR6U93GIC@gmail.com> (raw)
In-Reply-To: <auILs54TUcWXf3us@pedro-suse.tail5790ac.ts.net>

[-- Attachment #1: Type: text/plain, Size: 2641 bytes --]

On Wed Oct 28, 2026 at 3:56 PM CET, Pedro Falcato wrote:
> On Wed, Oct 28, 2026 at 02:47:27PM +0100, koraynilay wrote:
>> Add provenance time (ptime), indicating the time when a file or
>> directory was created. This is user-settable via file_setattr() and
>> retrievable via statx(2) (using STATX_PTIME) or file_getattr().
>> 
>> The semantics of when to preserve this new timestamp are the same as
>> mtime, the idea being that there is a correspondence like this:
>> 
>> ctime <-> btime
>> mtime <-> ptime
>> 
>> so every operation (copying, moving, ...) that currently preserves mtime
>> should also preserve ptime.
>> 
>> Furthermore, in order to avoid the legacy FS_IOC_FSSETXATTR accepting
>> FS_XFLAG_PTIME, add an FS_FILE_ATTR_XFLAGS_MASK mask to support new
>> xflags, and use it in fileattr_to_file_attr()/file_attr_to_fileattr() to
>> allow ptime to be used with the file_setattr()/file_getattr() syscalls.
>
> Random comment, but: could this be doable with xattrs instead? I'm not sure
> where I would put the xattrs code (if in userspace exclusively, or if hooking
> the VFS up with this, or if doing it on the filesystem side), but it would
> surely be less disruptive than modifying a bunch of filesystems one-by-one.
>

Thanks for the comment, I actually wanted to include the "why not xattr"
explanation in the cover letter but totally forgot lol.

I actually have been using fully userspace xattrs[1] for a few months,
mostly for backups, and it "works"; but last week I wanted to merge 2
FSs (and have another merge I have to do), so I ran [1] on all files and
then compared all metadata/data between source and destination and
noticed there were quite a lot of files that didn't have the xattr set.
So I looked online and learned that xattrs only work on regular
files/directories, not on symlinks or anything else (and the missing
ones were of symlinks).
This is what prompted me to search more if anyone had already proposed a
new timestamp (instead of making btime settable) and found the linked
email thread from april, which gave me the excuse to finally work on a
proper patch.

[1]: https://github.com/koraynilay/btime-to-xattr

> This patch is quite simple, but changing btrfs, then ext4, xfs, etc is a
> mess, and inevitably you can't get these timestamps until you upgrade your
> filesystems.

So yeah while I do agree it touches a lot of code that could create
problems, IMO this is the best solution and it would complete files'
timestamps like other OSs have (and this, I think, is necessary for
both backup/archival and migrations).

Best,
koraynilay

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2026-10-28 21:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-28 13:47 [RFC PATCH v2 0/2] add provenance time (ptime) koraynilay
2026-10-28 13:47 ` [RFC PATCH v2 1/2] vfs: " koraynilay
2026-10-28 14:56   ` Pedro Falcato
2026-10-28 21:12     ` koraynilay [this message]
2026-10-28 13:47 ` [RFC PATCH v2 2/2] btrfs: " koraynilay

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=DMGS4KQLY24Q.14MUTR6U93GIC@gmail.com \
    --to=koray.fra@gmail.com \
    --cc=aalbersh@kernel.org \
    --cc=brauner@kernel.org \
    --cc=defendthedisabled@gmail.com \
    --cc=djwong@kernel.org \
    --cc=dsterba@suse.com \
    --cc=jack@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mason@kernel.org \
    --cc=pfalcato@suse.de \
    --cc=viro@zeniv.linux.org.uk \
    /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