From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268978AbUJKP1h (ORCPT ); Mon, 11 Oct 2004 11:27:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S269111AbUJKPZk (ORCPT ); Mon, 11 Oct 2004 11:25:40 -0400 Received: from mx1.redhat.com ([66.187.233.31]:23461 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S269049AbUJKPUI (ORCPT ); Mon, 11 Oct 2004 11:20:08 -0400 From: David Howells In-Reply-To: <20041011142329.GJ4072@admingilde.org> References: <20041011142329.GJ4072@admingilde.org> <4161B664.70109@RedHat.com> <41661950.5070508@tequila.co.jp> <41667865.2000804@RedHat.com> To: Martin Waitz Cc: Linux filesystem caching discussion list , Steve Dickson , nfs@lists.sourceforge.net, linux-kernel , Clemens Schwaighofer , Alexander Viro Subject: Re: [Linux-cachefs] Re: [PATCH] NFS using CacheFS User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 Oct 2004 16:18:37 +0100 Message-ID: <10462.1097507917@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > > The 'fscache' flag will be coming along with the nfs4 support, since > > nfs4 mounting code does not have an open (unused) mounting flag.... > > is such a flag even neccessary? > The way I see fscache is that its operations will be no-ops anyway if you > haven't mounted any backing cache. There are two reasons: (1) The fscache middle bit builds up a cookie tree even if there are no backing caches. This means if the cache is added later (NFS root, for example), the netfs then starts caching immediately without requiring a remount. (2) NFS is not currently safe with respect to fscache in the following situation: mount warthog:/warthog/x /x mount warthog:/warthog /y Because NFS ends up with two superblocks for what is one set of filehandles. This means it tries to get the same cookies out of fscache twice, which fscache is ill-equipped to handle. This also introduces unnecessary (IMNSHO) aliasing in each client of inodes and pages both. I have a patch to fix NFS to cope with this by modifying the get_sb() method to allow the filesystem to override the automatic selection of super->s_root as the root dentry. However, Al Viro is leery of the patch for some reason. David From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: Re: [PATCH] NFS using CacheFS Date: Mon, 11 Oct 2004 16:18:37 +0100 Sender: linux-cachefs-bounces@redhat.com Message-ID: <10462.1097507917@redhat.com> References: <20041011142329.GJ4072@admingilde.org> <4161B664.70109@RedHat.com> <41661950.5070508@tequila.co.jp> <41667865.2000804@RedHat.com> Reply-To: Linux filesystem caching discussion list Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Cc: Linux filesystem caching discussion list , nfs@lists.sourceforge.net, Alexander Viro , linux-kernel , Steve Dickson , Clemens Schwaighofer Return-path: In-Reply-To: <20041011142329.GJ4072@admingilde.org> To: Martin Waitz List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-cachefs-bounces@redhat.com List-ID: > > The 'fscache' flag will be coming along with the nfs4 support, since > > nfs4 mounting code does not have an open (unused) mounting flag.... > > is such a flag even neccessary? > The way I see fscache is that its operations will be no-ops anyway if you > haven't mounted any backing cache. There are two reasons: (1) The fscache middle bit builds up a cookie tree even if there are no backing caches. This means if the cache is added later (NFS root, for example), the netfs then starts caching immediately without requiring a remount. (2) NFS is not currently safe with respect to fscache in the following situation: mount warthog:/warthog/x /x mount warthog:/warthog /y Because NFS ends up with two superblocks for what is one set of filehandles. This means it tries to get the same cookies out of fscache twice, which fscache is ill-equipped to handle. This also introduces unnecessary (IMNSHO) aliasing in each client of inodes and pages both. I have a patch to fix NFS to cope with this by modifying the get_sb() method to allow the filesystem to override the automatic selection of super->s_root as the root dentry. However, Al Viro is leery of the patch for some reason. David -- Linux-cachefs mailing list Linux-cachefs@redhat.com http://www.redhat.com/mailman/listinfo/linux-cachefs