On Thu, Jan 31, 2019 at 2:57 AM Chad Austin <chadaustin@xxxxxx> wrote: > > On a recent kernel with readdir caching and FUSE_NO_OPENDIR_SUPPORT > (and this follow-on patch: > https://patchwork.kernel.org/patch/10785105/ ), I benchmarked our > source control FUSE filesystem. With hot caches and zero requests > being made to userspace, I could do a full directory crawl of a major > subset of our repository in under 3 seconds. When I ran the same test > against ext4 and btrfs, it took between 3 and 6 seconds. Awesome! > > However, though we were correctly sending FUSE_NOTIFY_INVAL_ENTRY > whenever changing a directory inode's entry, this did not flush the > readdir pagecache. It looks to me like FUSE_NOTIFY_INVAL_ENTRY only > invalidates the readdir cache if the dcache has an entry with the > given name. Whether that's true is entirely out of userspace's hands. > > We worked around it by also explicitly sending FUSE_NOTIFY_INVAL_INODE > once per inode if we ever sent FUSE_NOTIFY_INVAL_ENTRY. But this > increases our invalidation traffic and seems unnecessary. > > What do you think about having FUSE_NOTIFY_INVAL_ENTRY also > unconditionally invalidate the readdir cache? Makes sense. Thanks, Miklos
