Re: [RFC] metadata updates vs. fetches (was Re: [PATCH v4] fs: Fix data race in inode_set_ctime_to_ts)

[Al Viro <viro@zeniv.linux.org.uk>]

On Mon, Nov 25, 2024 at 12:05:29AM +0100, Mateusz Guzik wrote:
> On Sun, Nov 24, 2024 at 11:10 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > So I mention the "rename and extend i_size_seqcount" as a solution
> > that I suspect might be acceptable if somebody has the motivation and
> > energy, but honestly I also think "nobody can be bothered" is
> > acceptable in practice.
> >
> 
> So happens recently the metadata ordeal also came up around getattr
> where a submitter wanted to lock the inode around it.

The posting Linus had been replying to:
https://lore.kernel.org/all/20241124215014.GA3387508@ZenIV/

> Until the day comes when someone has way too much time on their hands
> and patches it up (even that may encounter resistance though), I do
> think it would make sense to nicely write it down somewhere so for
> easy reference -- maybe as a comment above getattr and note around
> other places like the timespec helpers to read that.

See above.

For those who'd missed the getattr thread - the approach proposed and
NAKed there was to take ->i_rwsem (shared) in stat(2).  A non-starter
for obvious reasons, IMO.  Seqcount avoids those, but it would need to
be a pair of primitives used around the stores, with i_size_write()
*not* usable inside such scope.  Potential problems would be the
amount of time spent inside those scopes and amount of spinning it
would cause on the stat(2) side + the inode bloat.

All of that is modulo usefulness of such atomicity - nothing mentioned
so far seems to be a good reason to bother with all of that in the
first place...