On Tue, Oct 2, 2018 at 11:33 PM, Dan Schatzberg <dschatzb...@fb.com> wrote: > On 9/27/18, 9:59 AM, "Miklos Szeredi" <mik...@szeredi.hu> wrote: > >> On Thu, Sep 27, 2018 at 3:52 PM, Dan Schatzberg <dschatzb...@fb.com> wrote: >>> FUSE file reads are cached in the page cache, but symlink reads are >>> not. This patch enables FUSE READLINK operations to be cached which >>> can improve performance of some FUSE workloads. >>> >>> In particular, I'm working on a FUSE filesystem for access to source >>> code and discovered that about a 10% improvement to build times is >>> achieved with this patch (there are a lot of symlinks in the source >>> tree). >>> >>> Please provide feedback, I'm looking to flesh this out more. >> >> Need to think about how/when to invalidate the cached symlink >> contents. I think treating it like metadata (i.e. look at >> attr_timeout for validity) would be the simplest. >> >> Thanks, >> Miklos >> > > Any further thoughts on this? Just so I can confirm my understanding, > the attached patch will unconditionally cache READLINK responses > However, based on the entry timeout provided by the LOOKUP response, > Userspace can decide to invalidate this by providing a different inode on > a subsequent LOOKUP (e.g. during fuse_dentry_revalidate())
Indeed. > Would you like there to be a way to invalidate the cached symlink without > changing the inode via LOOKUP? No, that would make no sense, since symlink contents are not mutable. This was just a braino on my part. I still worry about backward compatibility, though. So we should add a flag to negotiate symlink caching in with the INIT request. Thanks, Miklos
