Date: Wed, 24 Jan 2001 13:11:50 +0100 From: Matthias Andree <matthias.andree@stud.uni-dortmund.de> To: Guy Harris <gharris@flashcom.net> Cc: 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: <20010124131150.B1839@emma1.emma.line.org> In-Reply-To: <20010124001701.F344@quadrajet.flashcom.com>; from gharris@flashcom.net on Wed, Jan 24, 2001 at 00:17:01 -0800 References: <20010123015612.H345@quadrajet.flashcom.com> <20010123162930.B5443@emma1.emma.line.org> <20010123111005.D344@quadrajet.flashcom.com> <m3r91t8vxv.fsf@emma1.emma.line.org> <20010124001701.F344@quadrajet.flashcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Jan 2001, Guy Harris wrote: > 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. That's a different problem. > 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. I tcpdumped Solaris <-> Linux conversation, on a Linux 2.2.17 kernel with nfs v3 patched (I'm off-site ATM and don't want to reboot the server with a different kernel remotely.) Here's what Solaris does for ls: 1. GETATTR 2. ACCESS - ask ONLY for READ 3. GETATTR Linux sends OK back with the READ permission bit set. > 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. Yes. That's not bad by itself, the Linux server is obviously broken and needs fixing. No action required on FreeBSD client part here. Linux can (I didn't check RFC 1813) probably still return ROFS in response to a later modification request. > 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? That's not the point. It won't help either, since FreeBSD ONLY sends three identical ACCESS requests with all 6 flags sets each time, it does not even try to access anything. -- Matthias Andree 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?20010124131150.B1839>