From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Sharp Subject: Re: nfs exporting my stacked fs Date: Fri, 30 May 2003 16:30:03 -0700 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20030530233003.GA15469@ccpu.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from covad-netfall.meer.net ([209.157.145.14]:29844 "EHLO eviltwins") by vger.kernel.org with ESMTP id S264046AbTE3XQn (ORCPT ); Fri, 30 May 2003 19:16:43 -0400 Received: from andy by eviltwins with local (Exim 3.35 #1 (Debian)) id 19LtJz-000431-00 for ; Fri, 30 May 2003 16:30:03 -0700 To: linux-fsdevel@vger.kernel.org Content-Disposition: inline In-Reply-To: List-Id: linux-fsdevel.vger.kernel.org On Sat, May 31, 2003 at 01:10:09AM +0200, Trond Myklebust wrote: > >>>>> " " == Bryan Henderson writes: > > > This is true in any instant, but for most NFS purposes, we also > > care about identifying a file uniquely over time, even when > > that time might involve sea changes such as a reboot. E.g. one > > would like to make sure that a file handle that referred to > > file A an hour ago still refers to file A now. > > According to RFC1813 (which clarifies common practices for RFC1094) > file handles are *unique*. More specifically: > > "If two file handles from the same server are equal, they must refer > to the same file, but if they are not equal, no conclusions can be > drawn." > > RFC1813 makes no exceptions to this rule. Including for time.... Yes. At first I was annoyed that the Linux NFS client peeks at the file handle, because sometimes I want to change it for the same file, but then it turns out that the solution to another problem of mine fixes that as well. And now it sounds like the v4 file handle won't be considered opaque for the client any more. As far as being able to find the right file from a file handle, no matter how dusty, my fs has the same problem as NFS in this regard. A bit of challenge on Linux if one hopes to maintain a proper dcache. > The one thing that is allowed, is that the server may revoke a > filehandle if (and only if) the file no longer exists, or if access to > the file has been revoked. > > > IOW: the condition you describe above is trivially observed... I take it then that the fsid returned by ->statfs is largely not used right now? My version of nfs-utils (1.0) doesn't support the fsid option in config files, so I've just hacked the kernel to get me through this part of the development phase. I'm guessing that all or part of this stuff is handled a bit differently in 2.5? a