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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 21/11/23 09:12, Ian Kent wrote:
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.

I've completely lost what we are talking about.


I think it was the introduction of listmount() earlier so my comment does

apply to that but it's getting just mount ids so the allocation isn't huge

even for a large number of mounts so I don't think there's a need for

complexity.


Then statmount() is retrieving the info for a single mount id, that's quite

specific info. and not that hard to estimate the needed allocation so the

error return and retry does seem like the most sensible thing.


The fact is that getting a list of mount ids and then working through them

meant you would be working with an outdated mounts list almost all the time.

That's nothing new for what this is used for and is sufficiently functional.


There are times when you do need a specific mount, such as SIGCHLD processing,

but then we are working with a specific mount id so it's not a problem.




Ian






[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux