On Wed, Aug 12, 2020 at 11:43 AM Steven Whitehouse [off-list ref] wrote:

Hi,

On 12/08/2020 09:37, Miklos Szeredi wrote:
[snip]

quoted

b) The awarded performance boost is not warranted for the use cases it
is designed for.

This is a key point. One of the main drivers for this work is the
efficiency improvement for large numbers of mounts. Ian and Karel have
already provided performance measurements showing a significant benefit
compared with what we have today. If you want to propose this
alternative interface then you need to show that it can sustain similar
levels of performance, otherwise it doesn't solve the problem. So
performance numbers here would be helpful.

Definitely.   Will measure performance with the interface which Linus proposed.

I'm not worried, though; the problem with the previous interface was
that it resulted in the complete mount table being re-parsed on each
individual event resulting in quadratic behavior.  This doesn't affect
any interface that can query individual mount/superblock objects.

Also - I may have missed this earlier in the discussion, what are the
atomicity guarantees with this proposal? This is the other key point for
the API, so it would be good to see that clearly stated (i.e. how does
one use it in combination with the notifications to provide an up to
date, consistent view of the kernel's mounts)

fsinfo(2) provides version counters on mount and superblock objects to
verify consistency of returned data, since not all data is returned in
a single call.  Same method could be used with the open/read based
interface to verify consistency in case multiple attributes/attribute
groups need to be queried.

Thanks,
Miklos