From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-f68.google.com ([209.85.166.68]:44792 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726699AbeJJPup (ORCPT ); Wed, 10 Oct 2018 11:50:45 -0400 Received: by mail-io1-f68.google.com with SMTP id x26-v6so3242408iog.11 for ; Wed, 10 Oct 2018 01:29:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20180927135211.31641-1-dschatzberg@fb.com> From: Miklos Szeredi Date: Wed, 10 Oct 2018 10:29:39 +0200 Message-ID: Subject: Re: [PATCH] fuse: enable caching of symlinks To: Dan Schatzberg Cc: Tejun Heo , Kernel Team , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Oct 2, 2018 at 11:33 PM, Dan Schatzberg wrote: > On 9/27/18, 9:59 AM, "Miklos Szeredi" wrote: > >> On Thu, Sep 27, 2018 at 3:52 PM, Dan Schatzberg 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