mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "koraynilay" <koray.fra@gmail.com>
To: "Jan Kara" <jack@suse.cz>, "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>,
	"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 0/2] add provenance time (ptime)
Date: Tue, 03 Nov 2026 15:26:20 +0100	[thread overview]
Message-ID: <DMLN8XHASPL4.1R3MI7CMA5KCD@gmail.com> (raw)
In-Reply-To: <upe7qvhod63zd724s7uiql6kanqyrcwplodoavcvqjt35vd4ee@s3iglizxejlr>

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

On Tue Nov 3, 2026 at 2:25 PM CET, Jan Kara wrote:
> On Tue 27-10-26 23:05:30, koraynilay wrote:
>> This is an initial implementation of a new timestamp to indicate the
>> time when a file/directory was initially created.
>> 
>> This patch series takes inspiration from the one by Sean Smith
>> <defendthedisabled@gmail.com> [1], but using
>> file_setattr()/file_getattr() as suggested by Darrick J. Wong
>> <djwong@kernel.org> in [2].
>> 
>> The semantics of this new timestamp should be at least these:
>> - it should be the same as btime on a newly created file
>> - it's user-settable, so it can be preserved for backups, filesystem
>>   conversions, archives and any similar operation
>> - it should be preserved every time mtime gets preserved
>> 
>> and the correspondence with the other timestamps is as follows:
>> 
>> ctime <-> btime
>> mtime <-> ptime
>
> One thing I miss in this series is an explanation what this new timestamp is
> good for. Because frankly, I don't miss such timestamp as a Linux user :).
>
> 								Honza

Hello, my concrete use-cases are backups and filesystem conversions.

For backups, my setup is btrfs and using btrbk (so btrfs send to my nas
with ssh) and the only missing thing from the backup is the timestamp of
file creation (which I'm currently working around using xattrs).

The situation that prompted me to finally start working on this RFC
PATCH was when I wanted to merge 2 btrfs FSs and the only way of doing
that (AFAIK at least) is using cp/rsync, which can't set the creation
time since btime is immutable. The workaround I used was the same as
with backups, so with xattrs, but noticed that some files (symlinks)
wouldn't accept xattrs, so I looked into it and found out xattrs are
only for regular files/dirs.

(also see https://lore.kernel.org/DMGS4KQLY24Q.14MUTR6U93GIC@gmail.com/)

>
>> 
>> Examples:
>> 1) a .zsh_history file created in 2019, then after a few years the user
>>    decides to switch to another filesystem, copying the .zsh_history to
>>    the new home, in that case btime would have the timestamp of the copy
>>    and ptime would have the 2019 timestamp (just like mtime would have
>>    been preserved)
>> 2) a symlink created in 2020 from the home directory to a /path going
>>    through the same process as the .zsh_history, in this case it would
>>    also make sense to sync the ptime to the 2020 timestamp instead of
>>    keeping only the btime (so the inode creation time).

And as in these examples, keeping the original creation time for
everything is valuable to some users (like me) and allows for a true 1:1
clone of files between filesystems without losing any metadata (I can't
think of any other file metadata (not permissions) other than the
creation time that is still missing).

As for non-concrete use-cases, adding this timestamp would be good for
completeness IMO, since the creation time of file data is not a thing
on linux yet (but is on windows and mac).

Thanks,
koraynilay

>> The proof-of-concept code (for testing) for stat(1) and cp(1) is
>> available at https://github.com/koraynilay/coreutils (master branch)
>> (Note: these coreutils code changes are a prototype and won't be
>> submitted upstream as-is, but they work as expected in simple stat and
>> cp -a/--preserve=ptime tests)
>> 
>> Lastly, the name "provenance" and "ptime" are not final, I personally
>> don't have a strong opinion on any name, but while testing with stat(1)
>> I noticed that "Provenance" is definitely too long for the normal
>> output, so another option which would fit well is "Origin time",
>> abbreviated as "ntime" (OrigiN time) and not as "otime", as that would
>> conflict with btrfs' internal naming and create confusion.
>> 
>> Thanks.
>> 
>> [1]: https://lore.kernel.org/20260405195007.1306-2-DefendTheDisabled@gmail.com
>> [2]: https://lore.kernel.org/20260407014129.GC6192@frogsfrogsfrogs
>> 
>> koraynilay (2):
>>   vfs: add provenance time (ptime)
>>   btrfs: add provenance time (ptime)
>> 
>>  fs/btrfs/btrfs_inode.h          |  4 ++++
>>  fs/btrfs/delayed-inode.c        |  6 ++++++
>>  fs/btrfs/inode.c                | 17 ++++++++++++++++-
>>  fs/btrfs/ioctl.c                | 12 +++++++++++-
>>  fs/btrfs/print-tree.c           |  1 +
>>  fs/btrfs/tree-log.c             |  3 +++
>>  fs/file_attr.c                  | 24 ++++++++++++++++++++++--
>>  fs/stat.c                       |  2 ++
>>  include/linux/fileattr.h        | 27 ++++++++++++++++++++++++---
>>  include/linux/stat.h            |  1 +
>>  include/uapi/linux/btrfs_tree.h |  3 ++-
>>  include/uapi/linux/fs.h         |  8 +++++++-
>>  include/uapi/linux/stat.h       |  7 ++++++-
>>  13 files changed, 105 insertions(+), 10 deletions(-)
>> 
>> 
>> base-commit: 21a7f44fd0765fcc5194130b28767786eba1d1e7
>> -- 
>> 2.56.0
>> 



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

      reply	other threads:[~2026-11-03 14:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 22:05 koraynilay
2026-10-27 22:05 ` [RFC PATCH 1/2] vfs: " koraynilay
2026-10-27 22:05 ` [RFC PATCH 2/2] btrfs: " koraynilay
2026-11-03 13:25 ` [RFC PATCH 0/2] " Jan Kara
2026-11-03 14:26   ` koraynilay [this message]

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=DMLN8XHASPL4.1R3MI7CMA5KCD@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=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

all inboxes | Powered by JetHome®