From: Peter Åstrand (peter@cendio.se)
Date: 03/20/02-01:36:26 PM Z
Date: Wed, 20 Mar 2002 20:36:26 +0100 (CET) From: Peter Åstrand <peter@cendio.se> Subject: Re: Mount point crossing & space_avail Message-ID: <Pine.LNX.4.44.0203202024560.15634-100000@sofie.lambo.student.liu.se> > I would be opposed to adding a "list exported file systems" op. Current > file systems tend to be fairly static, but I could imagine a server that > builds its tree dynamically. Plan 9, for example, allows you to build > arbitrarily complex name spaces. A Plan 9 server can return NFS4ERR_NOTSUPP for a "list exported file systems" op, if it is unable to return any information that makes sense. We already have lots of ops that can return NOTSUPP, like OPENATTR. (Btw, why can operations like OPEN and RENAME return NOTSUPP? Aren't these mandatory? If NOTSUPP are allowed for OPEN, shouldn't it be allowed for LOCK etc as well?) > Afs solves this problem by providing a separate command that you can run > on any directory to find out how much space is available in that file > system. If you have this, which can be supported by the current v4 > protocol, I don't think you need a way to query the server for a list of > file systems. This command then walks the entire directory tree, right? Yes, that would work. But it does not scale very well. The response time is proportional to the number of directories in the tree. A slightly to ugly solution to be usable by an ordinary "df" command, IMHO. -- Peter Åstrand Telephone: +46-13-21 46 00 Cendio Systems E-mail: peter@cendio.se Teknikringen 3 583 30 Linköping Sweden
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:37 AM Z CST