Path: utzoo!attcan!uunet!convex!convex.convex.com!thurlow From: thurlow@convex.com (Robert Thurlow) Newsgroups: comp.protocols.nfs Subject: Re: NFS writes and fsync(). Message-ID: Date: 21 Oct 90 17:24:40 GMT References: <1990Oct9.152612@objy.objy.com> <72781@sgi.sgi.com> <143983@sun.Eng.Sun.COM> Sender: usenet@convex.com Lines: 34 In <143983@sun.Eng.Sun.COM> beepy@ennoyab.Eng.Sun.COM (Brian Pawlowski) writes: >[Vernon: Do you feel like posting an enumerated prioritized list of >missing features in NFS--with some measure of how important that feature >is? That should start an interesting discussion--I'd like to see it.] I'll bite. I see these as problems that needed to be solved a year ago in a minor protocol revision almost orthogonal to NeFS: - There is nothing in the mount protocol to carry any filesystem info beyond the filehandle. For example, this prevents me from warning my client user that the filesystem was exported read-only at mount time or that the filesystem needs to be accessed via the Secure protocol. AUTH_KERB will make this worse. - access(2) badly needs to go over-the-wire. "Guessing" permissions from attributes is completely inadequate when we have root access issues, UID/GID mapping issues with Secure NFS, access control lists, and other gremlins. We have a perfectly good file server; why not ask the owner of the resource. - It should be possible to do exclusive file creates over the wire. With even a bit flag, the server would be able to do the work which the client now has to make vague stabs at. What hurts is that I know exactly how to implement each of these, but can't do so until Sun blesses a protocol revision. I found NeFS very interesting, but would really like a way to fix some things *now*. #include Rob T -- Rob Thurlow, thurlow@convex.com or thurlow%convex.com@uxc.cso.uiuc.edu ---------------------------------------------------------------------- "This opinion was the only one available; I got here kind of late."