From: Brent Callaghan (brent@jurassic)
Date: 03/11/97-12:44:03 PM Z
Date: Tue, 11 Mar 1997 10:44:03 -0800 (PST) From: Brent Callaghan <brent@jurassic> Subject: re: attributes (optionalness of) Message-ID: <Roam.1.1.858105843.5884.brent@jurassic> > But the issue is not how much can you do. The issue is can you do all that > is necessary. This is perhaps what it comes down to. I don't think the protocol can guarantee this. For instance, there are several on this mailing list who have experience with implementing and/or maintaining MVS NFS server. There are some good horror stories in the implementation of this server. It pushed the limits of NFS server implementations; getting the attributes of MVS filesystems to map into a fattr is an exercise in imagination. I wouldn't consider using an MVS NFS server as a repository for my home directory - my applications would break en mass. However, as a means for providing access for heterogeneous clients to MVS datasets, it is very successful. If we pick a mandatory set of file attributes that an MVS/NFS server cannot support - is NFS v4 no longer supportable on that platform ? I agree that zero attributes is probably non-useful and NFS servers will make a best effort to support as many attributes as they can. I think it's unecessarily restrictive to lock out potentially useful NFS implementations because they don't support a minimum set. Brent
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:30 AM Z CST