From: Craig_Everhart@transarc.com
Date: 03/19/99-04:33:34 PM Z
Message-Id: <Yqwh2yuSMVcC1kH9Y0@transarc.com> Date: Fri, 19 Mar 1999 17:33:34 -0500 (EST) From: Craig_Everhart@transarc.com Subject: Re: fsid.major/minor Excerpts from transarc.external.nfs4-wg: 18-Mar-99 RE: fsid.major/minor "Noveck, Dave"@netapp.co (5179*) > It also brings up the issue of how do you represent availability > of disk space in a per-world strategy where there are multiple > disk allocation domains within a client filesystem. > I assume that AFS and DFS have had to deal with this latter > issue. What AFS and DFS basically do in this regard is punt. In a tiny nutshell: The client-side mount, that ``df'' sees, is for the top level fileset/volume of a tree-structured file system that is generally represented on a collection of file servers all at once, where objects in the server specify links from places in one fileset/volume to the root directories of other filesets/volumes. (It's ``fileset'' to DFS and ``volume'' to AFS.) Each fileset/volume has a quota, but there are multiple filesets/volumes on a given storage device, and each storage device has a total capacity. The separate filesets/volumes do not appear as separate client-side mounts, but are transparently navigated. The (AFS/DFS) client knows about the distinction between filesets/volumes, but it doesn't reflect this to the client's mount table. Thus, we have two problems: for every directory (say), there are two limits on fresh allocation: the quota for the fileset/volume, and the actual space available in the storage device. Thus my suggestion of being able to return space available for the major/minor fsid (the fileset/volume) and for the major part alone (the storage device). I figured that something like this would arise not just for re-exporting AFS or DFS, but also for an architecture like what Mike E. was proposing about mobile subtrees: there would be some storage limit for the subtree and a separate limit for the enclosing structure. Maybe I missed a point in that I would fully have expected the client to be asking about free space at any point in its directory tree, not just at the root of its client-side mounts. While the ``df'' command won't do anything interesting in this regard, programs that ask about how much space is available for writing a given file could be told something closer to being true. While there's a statvfs() call on Solaris to check something like this, it looks from the vfs-op level not to be able to distinguish different files within the client-mounted file system, so maybe that's another fix to add. Probably a double-level FSID is OK. I'd just like a way to express that there's an allocation limit imposed by the fileset/volume that's potentially not the same throughout a client mount. Maybe that's actually not what would be achieved here; the transparent inter-fileset mounts might get in the way. Thinking about this from the NFS perspective, NFS wants to mount a single directory tree, and I bet that both the Eisler mobile filesets and the NetApp quota trees present single directory trees from servers. Until NFS servers want to include transparent referrals, of course, which I guess is what it means to have the capacity to follow server-side mounts. At that point, do you get a new fsid.minor? A new fsid.major as well? How can you tell? But since I can express the concern in purely NFS terms, it seems that the community would want to be able to handle the issue, too. Craig
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:53 AM Z CST