From: Mike Eisler (mre@eng.sun.com)
Date: 02/22/99-07:34:43 PM Z
Date: Mon, 22 Feb 1999 17:34:43 -0800 (PST) From: Mike Eisler <mre@eng.sun.com> Subject: Re: comments on draft-shepler-nfsv4-02-01.html Message-ID: <Roam.SIMC.2.0.6.919733683.4813.mre@eng.sun.com> > > > Name: read_max > > > In the event this attribute doesn't exist, I'd simply try > > a read of size X, and either get X bytes, or get a short read. > > > > Either make it mandatory or get rid of it, but as RECOMMENDED, > > I consider it it of no use. > > > > Name: write_max > > > I don't think we need to make this MANDATORY because obviously > > if a server say supports only read only file systems, WRITE is > > nonsequitur. But I'd like to see some language that says that if > > the server supports WRITEs on the object, it is strongly RECOMMENDED > > that it support this attribute, because otherwise the client > > may guess too conservatively or too liberally, and the result > > is that performance suffers and/or bandwidth is wasted. > > The benefits of having this are clear, as you say. The only argument > the other way is about whether it is really essential for a minimalist > server to implement this to be useful. True. Ok, I withdraw my comment about read_max. As for write_max I think we are in agreement, but I just want the language on the attribute to be strong as I described above. > > > Name: fsid > > > Craig Everhart said several months ago that the case can be > > made that the fsid should be a tuple, at least a two-tuple. > > I agree. The DCE/DFS local file system needs it, and it would > > also ease implementation of file sets. So I think fsid should be > > split into fsid.major and fsid.minor, each of type uint64. > > This sounds good to me. > > > Given that, the attributes that apply to a "filesystem" ought to > > have counter parts that apply to an fsid.minor as well. > > Could you please expand on this? Would we want to duplicate all of > those types of fields? Or would we want to sort somehow? I would > think the client would want to find out the limits (e.g. free space) > and characteristics of the directory under operation, and not care > to think hard about two sets of parameters. "free space" is an excellent example of an attribute that could have a different value for each fsid.minor within the same fsid.major. If the client is aware that two different file objects have a same fsid.major but different fsid.minor, then the client will want to know the free space on the different fsid.minor's. Say the application is copying a file to multiple directories, and each directory has different fsid.minor. -mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:41 AM Z CST