From: Jan Kara <jack@suse.cz>
To: Dave Chinner <david@fromorbit.com>
Cc: Jeff Layton <jlayton@kernel.org>,
Amir Goldstein <amir73il@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Kent Overstreet <kent.overstreet@linux.dev>,
Christian Brauner <brauner@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
John Stultz <jstultz@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Stephen Boyd <sboyd@kernel.org>,
Chandan Babu R <chandan.babu@oracle.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Theodore Ts'o <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>, Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.de>, David Howells <dhowells@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-mm@kvack.org,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing
Date: Wed, 1 Nov 2023 11:16:48 +0100 [thread overview]
Message-ID: <20231101101648.zjloqo5su6bbxzff@quack3> (raw)
In-Reply-To: <ZUF4NTxQXpkJADxf@dread.disaster.area>
On Wed 01-11-23 08:57:09, Dave Chinner wrote:
> 5. When-ever the inode is persisted, the timestamp is copied to the
> on-disk structure and the current change counter is folded in.
>
> This means the on-disk structure always contains the latest
> change attribute that has been persisted, just like we
> currently do with i_version now.
>
> 6. When-ever we read the inode off disk, we split the change counter
> from the timestamp and update the appropriate internal structures
> with this information.
>
> This ensures that the VFS and userspace never see the change
> counter implementation in the inode timestamps.
OK, but is this compatible with the current XFS behavior? AFAICS currently
XFS sets sb->s_time_gran to 1 so timestamps currently stored on disk will
have some mostly random garbage in low bits of the ctime. Now if you look
at such inode with a kernel using this new scheme, stat(2) will report
ctime with low bits zeroed-out so if the ctime fetched in the old kernel was
stored in some external database and compared to the newly fetched ctime, it
will appear that ctime has gone backwards... Maybe we don't care but it is
a user visible change that can potentially confuse something.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2023-11-01 10:16 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 17:41 [PATCH RFC 0/9] fs: multigrain timestamps (redux) Jeff Layton
2023-10-18 17:41 ` [PATCH RFC 1/9] fs: switch timespec64 fields in inode to discrete integers Jeff Layton
2023-10-18 17:41 ` [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing Jeff Layton
2023-10-18 19:18 ` Linus Torvalds
2023-10-18 20:47 ` Jeff Layton
2023-10-18 21:31 ` Linus Torvalds
2023-10-18 21:52 ` Jeff Layton
2023-10-19 9:29 ` Christian Brauner
2023-10-19 11:28 ` Jeff Layton
2023-10-19 22:02 ` Dave Chinner
2023-10-20 12:12 ` Jeff Layton
2023-10-20 20:06 ` Linus Torvalds
2023-10-20 20:20 ` Linus Torvalds
2023-10-20 21:05 ` Jeff Layton
2023-10-22 22:17 ` Dave Chinner
2023-10-23 14:45 ` Jeff Layton
2023-10-23 23:26 ` Dave Chinner
2023-10-24 0:18 ` Linus Torvalds
2023-10-24 3:40 ` Dave Chinner
2023-10-24 4:10 ` Linus Torvalds
2023-10-24 7:08 ` Amir Goldstein
2023-10-24 18:40 ` Jeff Layton
2023-10-25 8:05 ` Dave Chinner
2023-10-25 10:41 ` Amir Goldstein
2023-10-25 12:25 ` Jeff Layton
2023-10-26 2:20 ` Dave Chinner
2023-10-26 5:42 ` Amir Goldstein
2023-10-27 10:35 ` Jeff Layton
2023-10-30 22:37 ` Dave Chinner
2023-10-30 23:11 ` Linus Torvalds
2023-10-31 1:42 ` Dave Chinner
2023-10-31 7:03 ` Amir Goldstein
2023-10-31 10:30 ` Christian Brauner
2023-10-31 11:29 ` Jeff Layton
2023-10-31 21:57 ` Dave Chinner
2023-10-31 23:02 ` Darrick J. Wong
2023-10-31 23:47 ` Dave Chinner
2023-11-01 10:16 ` Jan Kara [this message]
2023-11-01 11:38 ` Amir Goldstein
2023-11-02 10:17 ` Jeff Layton
2023-11-01 20:10 ` Linus Torvalds
2023-11-01 21:34 ` Trond Myklebust
2023-11-01 22:23 ` Linus Torvalds
2023-11-01 22:45 ` Trond Myklebust
2023-11-01 23:29 ` Dave Chinner
2023-11-02 10:29 ` Jeff Layton
2023-11-02 10:15 ` Jeff Layton
2023-10-31 23:12 ` Darrick J. Wong
2023-11-01 8:08 ` Amir Goldstein
2023-10-31 11:26 ` Jeff Layton
2023-10-31 19:43 ` John Stoffel
2023-10-31 11:04 ` Jeff Layton
2023-10-31 12:22 ` Jan Kara
2023-10-31 12:55 ` Jeff Layton
2023-10-30 23:34 ` ronnie sahlberg
2023-10-24 14:24 ` Jeff Layton
2023-10-24 19:06 ` Jeff Layton
2023-10-24 19:40 ` Linus Torvalds
2023-10-24 20:19 ` Jeff Layton
2023-10-31 10:26 ` Christian Brauner
2023-10-31 13:55 ` Jeff Layton
2023-10-19 22:00 ` Thomas Gleixner
2023-10-19 22:41 ` Jeff Layton
2023-10-18 17:41 ` [PATCH RFC 3/9] timekeeping: add new debugfs file to count multigrain timestamps Jeff Layton
2023-10-18 17:41 ` [PATCH RFC 4/9] fs: add infrastructure for " Jeff Layton
2023-10-18 17:41 ` [PATCH RFC 5/9] fs: have setattr_copy handle multigrain timestamps appropriately Jeff Layton
2023-10-18 17:41 ` [PATCH RFC 6/9] xfs: switch to multigrain timestamps Jeff Layton
2023-10-18 17:41 ` [PATCH RFC 7/9] ext4: " Jeff Layton
2023-10-18 17:41 ` [PATCH RFC 8/9] btrfs: convert " Jeff Layton
2023-10-18 17:41 ` [PATCH RFC 9/9] tmpfs: add support for " Jeff Layton
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=20231101101648.zjloqo5su6bbxzff@quack3 \
--to=jack@suse.cz \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=clm@fb.com \
--cc=david@fromorbit.com \
--cc=dhowells@redhat.com \
--cc=djwong@kernel.org \
--cc=dsterba@suse.com \
--cc=hughd@google.com \
--cc=jack@suse.de \
--cc=jlayton@kernel.org \
--cc=josef@toxicpanda.com \
--cc=jstultz@google.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=sboyd@kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--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;
as well as URLs for NNTP newsgroup(s).