Messages in this thread | | | From | Miklos Szeredi <> | Date | Wed, 1 Apr 2020 18:40:13 +0200 | Subject | Re: Upcoming: Notifications, FS notifications and fsinfo() |
| |
On Wed, Apr 1, 2020 at 6:07 PM David Howells <dhowells@redhat.com> wrote: > > Miklos Szeredi <miklos@szeredi.hu> wrote: > > > I've still not heard a convincing argument in favor of a syscall. > > From your own results, scanning 10000 mounts through mountfs and reading just > two values from each is an order of magnitude slower without the effect of the > dentry/inode caches. It gets faster on the second run because the mountfs > dentries and inodes are cached - but at a cost of >205MiB of RAM. And it's > *still* slower than fsinfo().
Already told you that we can just delete the dentry on dput_final, so the memory argument is immaterial.
And the speed argument also, because there's no use case where that would make a difference. You keep bringing up the notification queue overrun when watching a subtree, but that's going to be painful with fsinfo(2) as well. If that's a relevant use case (not saying it's true), might as well add a /mnt/MNT_ID/subtree_info (trivial again) that contains all information for the subtree. Have fun implementing that with fsinfo(2).
Thanks, Miklos
| |