From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268922AbUJEKCt (ORCPT ); Tue, 5 Oct 2004 06:02:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268944AbUJEKCt (ORCPT ); Tue, 5 Oct 2004 06:02:49 -0400 Received: from mx1.redhat.com ([66.187.233.31]:65466 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S268922AbUJEKCp (ORCPT ); Tue, 5 Oct 2004 06:02:45 -0400 From: David Howells In-Reply-To: <1096926837.22446.141.camel@lade.trondhjem.org> References: <1096926837.22446.141.camel@lade.trondhjem.org> <4161B664.70109@RedHat.com> To: Trond Myklebust Cc: Steve Dickson , nfs@lists.sourceforge.net, Linux filesystem caching discussion list , linux-kernel Subject: 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: Tue, 05 Oct 2004 11:01:19 +0100 Message-ID: <6047.1096970479@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > This is my one and only real gripe about it. The posix mount option is > clearly documented, so we really cannot play around with it. Why can't > you just add a separate cachefs flag? That's just for the prototype. It will be changed later. It's also a stand-in for the superblock un-aliasing patch. > I'm a bit worried about the use of the raw IP address in > nfs_cache_server_match(). It seems to me that when we add the NFSv4.1 > support for trunking over several different transport mechanisms (RDMA, > IPv4/v6 etc) on the same mountpoint, then we may end up with a problem. We > can probably leave it in for now, but later we may want to consider > switching to using server->hostname or something equivalent. There needs to be some way of matching NFS file handle sets in the cache if you want persistant caches. The only way I could see was to use IP addr and port number for NFS. However, changing this later is trivial. If you bump the version number in the netfs definition, then cachefs will nuke existing data in the cache that isn't of the expected format. David From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: [PATCH] NFS using CacheFS Date: Tue, 05 Oct 2004 11:01:19 +0100 Sender: linux-kernel-owner@vger.kernel.org Message-ID: <6047.1096970479@redhat.com> References: <1096926837.22446.141.camel@lade.trondhjem.org> <4161B664.70109@RedHat.com> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Cc: Steve Dickson , nfs@lists.sourceforge.net, Linux filesystem caching discussion list , linux-kernel Return-path: In-Reply-To: <1096926837.22446.141.camel@lade.trondhjem.org> To: Trond Myklebust List-ID: > This is my one and only real gripe about it. The posix mount option is > clearly documented, so we really cannot play around with it. Why can't > you just add a separate cachefs flag? That's just for the prototype. It will be changed later. It's also a stand-in for the superblock un-aliasing patch. > I'm a bit worried about the use of the raw IP address in > nfs_cache_server_match(). It seems to me that when we add the NFSv4.1 > support for trunking over several different transport mechanisms (RDMA, > IPv4/v6 etc) on the same mountpoint, then we may end up with a problem. We > can probably leave it in for now, but later we may want to consider > switching to using server->hostname or something equivalent. There needs to be some way of matching NFS file handle sets in the cache if you want persistant caches. The only way I could see was to use IP addr and port number for NFS. However, changing this later is trivial. If you bump the version number in the netfs definition, then cachefs will nuke existing data in the cache that isn't of the expected format. David