Date: Wed, 24 Jan 2001 00:17:01 -0800 From: Guy Harris <gharris@flashcom.net> To: Matthias Andree <ma@dt.e-technik.uni-dortmund.de> Cc: Guy Harris <gharris@flashcom.net>, Linux NFS mailing list <nfs@lists.sourceforge.net>, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: [NFS] Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export Message-ID: <20010124001701.F344@quadrajet.flashcom.com> In-Reply-To: <m3r91t8vxv.fsf@emma1.emma.line.org>; from ma@dt.e-technik.uni-dortmund.de on Wed, Jan 24, 2001 at 04:34:36AM %2B0100 References: <20010123015612.H345@quadrajet.flashcom.com> <20010123162930.B5443@emma1.emma.line.org> <20010123111005.D344@quadrajet.flashcom.com> <m3r91t8vxv.fsf@emma1.emma.line.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 24, 2001 at 04:34:36AM +0100, Matthias Andree wrote: > > (Perhaps it would've been better had the V3 protocol specified that > > either 0 or an NFS3ERR_xxx value be supplied for each of the permission > > bits checked, although that raises the question of whether any server > > would, say, allow read access and allow write access but disallow > > simultaneous read/write access.) > > No, the plan is simple. In the ACCESS call, the client asks if it has a > certain set of permissions, the sender weeds the actions the client may > not take at the moment of the ACCESS call, and returns a possibly > stripped-down set of allowed actions (which may then change > later). There's nothing wrong with this approach. The problem is that it only allows the client to know what it can or can't do; it doesn't let the client know, in more detail, *why* it can't do the things it's not allowed to do. For example, a UNIX "open()" call that calls an "access" vnode operation couldn't, if that file is mounted over NFS, find out that the open for writing is forbidden because the file system is read-only; even if that's the reason, the answer you get back is probably EACCES (that's what happens in the Solaris NFS, for example). BTW, I suspect the reason why FreeBSD is seeing a problem and Solaris isn't *might* be because FreeBSD is, at least if it's caching the results of ACCESS requests, sending over the wire an ACCESS request with all the bits turned on - the intent is, presumably, to find out as much as you can in one ACCESS call, even if you don't need all that information right now - which would provoke the Linux server to return an EROFS error rather than READ|EXECUTE|LOOKUP. If Solaris doesn't do that (I think Solaris *does* cache ACCESS replies, but it may, when it gets the reply back, cache only the answers to the questions it asked and, if another question is asked later and the answer to that question wasn't cached, ask that other question over the wire), then it may be that: on Solaris, an operation that doesn't require write permission causes an ACCESS request to go over the wire with none of MODIFY, EXTEND, or DELETE set, so Linux replies with a bitset of those operations that are actually allowed and, if the operation in question is one of them, the access vnode op returns "OK"; on FreeBSD, an operation that doesn't require write permission causes an ACCESS request to go over the wire with *all* bits set, so Linux replies with EROFS even though the operation is perfectly OK on a read-only file system, and the operation (e.g., opening a directory in order to list its contents) fails with EROFS. This means another workaround may be to set the "vfs.nfs.access_cache_timeout" sysctl value to 0, which turns off access reply caching. However, if I remember correctly something Brian Pawlowski mentioned a while ago, that can hurt NFS performance; I don't remember the details, but I seem to remember that access reply caching was being disabled on FreeBSD for some reason at some point (I also vaguely remember Mike Smith being involved in the discussion; Mike, if you're listening, do you remember any of this? Brian's out of town right now, and I'm at home rather than the office so I can't plow through my work mail archives). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010124001701.F344>