From: Peter Staubach (staubach@nyday.eng.sun.com)
Date: 05/18/99-11:40:54 AM Z
Date: Tue, 18 May 1999 09:40:54 -0700 (PDT) From: Peter Staubach <staubach@nyday.eng.sun.com> Message-Id: <199905181640.JAA80479@nyday.eng.sun.com> Subject: Re: New file handle section (hard links) > > It's been an interesting discussion, but I haven't yet > seen a strong rationale for the additional filehandle > restriction: that linked files have the same filehandle. > > There's already a requirement that linked files have > the same fsid and fileid, I don't think we disagree > on that. A client can depend on those if it needs to > know whether two files are the same, e.g. the UNIX > "cp" command checks these to make sure that it's > not copying a file over itself. > > As Uresh mentioned, our servers already hand out different > filehandles for for the export of two directories within the > same server filesystem. This means that there could be a > linked file that can be reached with two different > filehandles. > Well, yes and no. A client can mount a directory hierarchy from only one export point. The client would have to mount each individual export hierarchy separately. Thus, to the client, this file would correctly appear to be two different files. The issue here is one file, with more than one name, each inside of the same export point. To be specific -- A server exports /export. The names, /export/a and /export/b, are hard linked. The client mounts server:/export on /mnt. I believe that the file handles for /mnt/a and /mnt/b should be the same. If this is not true, then operating system semantics to /mnt/a and /mnt/b may be compromised and/or i/o performance when reading or writing to them. > A "one file, one filehandle" restriction would therefore > limit v4 servers to no more than one export per server > filesystem - while v2 and v3 servers can have as many > exports/filesystem as they like. I don't think sysadmins > would take kindly to this. > > Again, I think "one file, one filehandle" is a good > recommendation for servers, but clients shouldn't depend on it. > If clients can't depend upon it, then what use is it? Things that can't be depended upon and especially those which can't be detected and recovered from, can't be used when correctness and reliability are issues. ps
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:04 AM Z CST