[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231019-fluor-skifahren-ec74ceb6c63e@brauner>
Date: Thu, 19 Oct 2023 11:29:11 +0200
From: Christian Brauner <brauner@...nel.org>
To: Jeff Layton <jlayton@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,
John Stultz <jstultz@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Stephen Boyd <sboyd@...nel.org>,
Chandan Babu R <chandan.babu@...cle.com>,
"Darrick J. Wong" <djwong@...nel.org>,
Dave Chinner <david@...morbit.com>,
Theodore Ts'o <tytso@....edu>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
David Sterba <dsterba@...e.com>,
Hugh Dickins <hughd@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Amir Goldstein <amir73il@...il.com>, Jan Kara <jack@...e.de>,
David Howells <dhowells@...hat.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-xfs@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-btrfs@...r.kernel.org, linux-mm@...ck.org,
linux-nfs@...r.kernel.org
Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain
timestamp handing
> Back to your earlier point though:
>
> Is a global offset really a non-starter? I can see about doing something
> per-superblock, but ktime_get_mg_coarse_ts64 should be roughly as cheap
> as ktime_get_coarse_ts64. I don't see the downside there for the non-
> multigrain filesystems to call that.
I have to say that this doesn't excite me. This whole thing feels a bit
hackish. I think that a change version is the way more sane way to go.
>
> On another note: maybe I need to put this behind a Kconfig option
> initially too?
So can we for a second consider not introducing fine-grained timestamps
at all. We let NFSv3 live with the cache problem it's been living with
forever.
And for NFSv4 we actually do introduce a proper i_version for all
filesystems that matter to it.
What filesystems exactly don't expose a proper i_version and what does
prevent them from adding one or fixing it?
Powered by blists - more mailing lists