[lkml]   [2020]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Upcoming: Notifications, FS notifications and fsinfo()
On Wed, Apr 1, 2020 at 6:07 PM David Howells <> wrote:
> Miklos Szeredi <> 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).


 \ /
  Last update: 2020-04-01 18:40    [W:0.106 / U:2.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site