On Tue, Aug 16, 2022 at 1:14 PM Jan Harkes <jaharkes@xxxxxxxxxx> wrote:
>
> So good to know in advance a change like this is coming. I'll have to
> educate myself on this shared vs non-shared filldir.
Well, that change isn't necessarily "coming" - we've had this horrid
duality for years. "iterate_shared" goes back to 2016, and has been
marked "recommended" since then.
But the plain old "iterate" does continue to work, and having both is
only an ugly wart - I can't honestly claim that it's a big and
pressing problem.
But it would be *really* nice if filesystems did switch to it. For
most filesystems, it is probably trivial. The only real difference is
that the "iterate_shared" directory walker is called with the
directory inode->i_rwsem held for reading, rather than for writing.
End result: there can be multiple concurrent "readdir" iterators
running on the same directory at the same time. But there's still
exclusion wrt things like file creation, so a filesystem doesn't have
to worry about that.
Also, the concurrency is only between different 'struct file'
entities. The file position lock still serializes all getdents() calls
on any individual open directory 'struct file'.
End result: most filesystems probably can move to the 'iterate_shared'
version with no real issues.
Looking at coda in particular, I don't see any reason to not just
switch over to 'iterate_shared' with no code modifications at all.
Nothing in there seems to have any "I rely on the directory inode
being exclusively locked".
In fact, for coda in particular, it would be really nice if we could
just get rid of the old "iterate" function for the host filesystem
entirely. Which honestly I'd expect you could _also_ do, because
almost all serious local filesystems have long since been converted.
So coda looks like it could trivially move over. But I might be
missing something.
I suspect the same is true of most other filesystems, but it requires
people go check and go think about it.
Linus
