Invalidating cached FUSE directory entries

Invalidating cached FUSE directory entries

[Chad Austin]

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?

Re: Invalidating cached FUSE directory entries

[Miklos Szeredi]

On Thu, Jan 31, 2019 at 2:57 AM Chad Austin <chadaustin@fb.com> 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