From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: fscache recursive hang -- similar to loopback NFS issues Date: Tue, 05 Aug 2014 15:32:46 +0100 Message-ID: <20765.1407249166@warthog.procyon.org.uk> References: <20140721164044.2845f3fd@notabene.brown> <29057.1406650354@warthog.procyon.org.uk> <20140730071735.21ab7ca6@notabene.brown> <20140730121935.124bc7c9@notabene.brown> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-ID: <20764.1407249166.1@warthog.procyon.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-cachefs-bounces@redhat.com Errors-To: linux-cachefs-bounces@redhat.com To: Milosz Tanski Cc: NeilBrown , ceph-devel , "linux-fsdevel@vger.kernel.org" , "linux-cachefs@redhat.com" List-Id: ceph-devel.vger.kernel.org Milosz Tanski wrote: > FSCache already tracks statistics about how long writes and reads take > (at least if you enable that option). With those stats in hand we > should be able generate a default timeout value that works well and > avoid a tunable. If stat generation is going to be on all the time, it should probably use something other than atomic ops. NFS uses a set of ints on each CPU which are added together when needed. David