Linux-Fsdevel Archive on lore.kernel.org
 help / color / Atom feed
* Invalidating cached FUSE directory entries
@ 2019-01-31  1:57 Chad Austin
  2019-02-04  7:50 ` Miklos Szeredi
  0 siblings, 1 reply; 2+ messages in thread
From: Chad Austin @ 2019-01-31  1:57 UTC (permalink / raw)
  To: linux-fsdevel; +Cc: caustin

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?



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Invalidating cached FUSE directory entries
  2019-01-31  1:57 Invalidating cached FUSE directory entries Chad Austin
@ 2019-02-04  7:50 ` Miklos Szeredi
  0 siblings, 0 replies; 2+ messages in thread
From: Miklos Szeredi @ 2019-02-04  7:50 UTC (permalink / raw)
  To: Chad Austin; +Cc: linux-fsdevel, caustin

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-31  1:57 Invalidating cached FUSE directory entries Chad Austin
2019-02-04  7:50 ` Miklos Szeredi

Linux-Fsdevel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \
		linux-fsdevel@vger.kernel.org linux-fsdevel@archiver.kernel.org
	public-inbox-index linux-fsdevel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox