From: Brian Pawlowski (beepy@netapp.com)
Date: 03/19/99-06:48:29 PM Z
From: beepy@netapp.com (Brian Pawlowski) Message-Id: <199903200048.QAA00031@turok.netapp.com> Subject: Re: fsid.major/minor Date: Fri, 19 Mar 1999 16:48:29 -0800 (PST) Yeah, but what a "file system" is from a client's perspective has always been a strained concept. Obviously we are able to propagate the space allocation information contained in a qtree - which works out just dandy. But a "qtree" is not quite a "filesystem" - though it has several properties that one would typically consider those of a file system. It escapes me now what the NFS->AFS gateway did in the AFS product. Basically an AFS client acted as an NFS->AFS translator (and authentication proxy) allowing NFS clients to "mount" the *entire* AFS cell. Now, that cell could consist of many file *servers* never mind file systems, yet the user was unaware (other than from a performance perspective). Perhaps we should consider letting go of our preconceptions (or prejudices) of what a file system is supposed to be, along with letting go of our dogmas like "statelessness" - and just look for solutions that support or enhance current practice? beepy > Dave Hitz writes: > > Things would actually be a little better if the client would send over > > the FH you actually specified in the statfs() system call, rather than > > the FH for the mount point, because the way it is now, you cannot find > > the usage of the q-tree unless the mount point is inside the q-tree. > > It would be nicer if you could actually mount the root of the server, > > and then get "df" information based on the directory you pass in. > > Yes, this is a bit annoying. It goes to the mounted root because > the statfs() system call is implemented as as a filesystem operation: > VFS_STATVFS() rather than a vnode operation, e.g. VOP_STATVFS(). > > There's an implicit assumption in Solaris (and I'm sure other > UNIX clients) that the amount of space available is invariant > over a mounted filesystem, i.e. doesn't change from directory > to directory within a filesystem. > > Brent
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:54 AM Z CST