Re: proposed libc interface and man page for statmount(2)

Ian Kent
2023-11-21T01:12:47Z

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