On 21/11/23 08:58, Ian Kent wrote:
On 21/11/23 07:56, Ian Kent wrote:
On 20/11/23 20:34, Miklos Szeredi wrote:
On Mon, Nov 20, 2023 at 01:16:24PM +0100, Florian Weimer wrote:
Is the ID something specific to the VFS layer itself, or does it come
from file systems?
It comes from the VFS.
POSIX has a seekdir/telldir interface like that, I don't think file
system authors like it. Some have added dedicated data structures for
it to implement somewhat predictable behavior in the face of
concurrent
directory modification. Would this interface suffer from similar
issues?
The same issue was solved for /proc/$$/mountinfo using cursors.
The mounts are now using an rb-tree, I think the the cursor solution can
only work for a linear list, the case is very different.
This patchset removes the need for cursors, since the new unique
mount ID can be
used to locate the current position without having to worry about
deleted and
added mounts.
IIRC the problem with proc mounts traversals was because the lock was
taken
and dropped between reads so that mount entries could be deleted (not
sure
adding had quite the same problem) from the list in between reads.
Sounds like I'll need to look at the code but first though but an
rb-tree
can have mounts removed and new mounts inserted if the locks are dropped
if the retrieval is slit between multiple calls.
So I'm struggling to see why this isn't the same problem and I don't
think
introducing cursors in this case would work (thankfully, lets do this
again
please).
Mmm ... apologies for the poor description above.
That last bit is definitely "lets 'not' do this again please!"
IMHO keeping it simpler is much better.
The interface where a buffer is passed and overflow returns an error so
that one
can retry is far simpler and the in-kernel simplification of taking the
lock over
the whole retrieval is far less problematic.
If there's anything that could be useful then it's keeping a count of
the mounts
in a given namespace (I think we have such a count in nsproxy struct
already) and
adding a way to get that for storage needs estimation.
Ian
