From owner-freebsd-stable Wed Jan 24 0:17:21 2001 Delivered-To: freebsd-stable@freebsd.org Received: from c014.sfo.cp.net (c014-h022.c014.sfo.cp.net [209.228.12.86]) by hub.freebsd.org (Postfix) with SMTP id 4642937B402 for ; Wed, 24 Jan 2001 00:17:03 -0800 (PST) Received: (cpmta 7047 invoked from network); 24 Jan 2001 00:17:02 -0800 Received: from d8c81e5f.dsl.flashcom.net (HELO quadrajet.flashcom.com) (216.200.30.95) by smtp.flashcom.net (209.228.12.86) with SMTP; 24 Jan 2001 00:17:02 -0800 X-Sent: 24 Jan 2001 08:17:02 GMT Received: (from guy@localhost) by quadrajet.flashcom.com (8.9.3/8.9.3) id AAA00765; Wed, 24 Jan 2001 00:17:01 -0800 (PST) (envelope-from gharris) Date: Wed, 24 Jan 2001 00:17:01 -0800 From: Guy Harris To: Matthias Andree Cc: Guy Harris , Linux NFS mailing list , FreeBSD Stable Subject: Re: [NFS] Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export Message-ID: <20010124001701.F344@quadrajet.flashcom.com> References: <20010123015612.H345@quadrajet.flashcom.com> <20010123162930.B5443@emma1.emma.line.org> <20010123111005.D344@quadrajet.flashcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from ma@dt.e-technik.uni-dortmund.de on Wed, Jan 24, 2001 at 04:34:36AM +0100 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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