On Sat, Dec 1, 2018 at 11:00 AM Nikolaus Rath <Nikolaus@xxxxxxxx> wrote: > > On Nov 30 2018, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Thu, Nov 29, 2018 at 10:20 PM Nikolaus Rath <Nikolaus@xxxxxxxx> wrote: > >> > >> Hello, > >> > >> I am seeing an unexpectedly large number of getattr() and lookup() > >> requests being sent to userspace fuse. I am setting a very large > >> attr_timeout and entry_timeout, so I would have expected that the > >> maximum number of getattr() and lookup() requests is capped by the > >> number of distinct files in the filesystem plus the number of forget > >> requests. > >> > >> However, actual numbers are much higher. For example, when running tests > >> on a filesystem with 2960 directory entries, I am getting scenarios > >> with 203447 lookup requests, 12970 getattr requests, and zero forget > >> requests. > >> > >> Did I misunderstand something about how dentry and attribute caching > >> works? > > > > Debug log might be useful. > > Here you go! > > https://www.dropbox.com/s/tg4vyshz4g18sub/fuse-debug.log.xz?dl=1 $ grep LOOKUP fuse-debug.log | wc -l 20786 $ grep -A2 LOOKUP fuse-debug.log |grep "No such file or directory" | wc -l 20116 Since it's a lowlevel log, we can't see what the negative lookups are for, but by returning ENOENT it is guaranteed that the negative lookup can't be cached. Calling fuse_reply_entry() instead with a zero nodeid the negative entry can also be cached, which probably helps to reduce the number of lookups. See fuse_lib_lookup(): if (err == -ENOENT && f->conf.negative_timeout != 0.0) { e.ino = 0; e.entry_timeout = f->conf.negative_timeout; The GETATTR requests are due atime invalidations. There's no "noatime" mode yet, but it might make sense to add one. Thanks, Miklos
