On Dec 04 2018, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > 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. Uh, right. I forgot about that. Thanks! > The GETATTR requests are due atime invalidations. Could you elaborate? I'm not sure what that means here. What is an atime invalidation? Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
