On Wed, Aug 12, 2020 at 11:43 AM Steven Whitehouse <swhiteho@xxxxxxxxxx> wrote: > > Hi, > > On 12/08/2020 09:37, Miklos Szeredi wrote: > [snip] > > > > 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
