From owner-freebsd-stable Tue Jan 23 1:56:35 2001 Delivered-To: freebsd-stable@freebsd.org Received: from c014.sfo.cp.net (c014-h003.c014.sfo.cp.net [209.228.12.67]) by hub.freebsd.org (Postfix) with SMTP id B25CB37B6A0 for ; Tue, 23 Jan 2001 01:56:14 -0800 (PST) Received: (cpmta 18121 invoked from network); 23 Jan 2001 01:56:13 -0800 Received: from d8c81e5f.dsl.flashcom.net (HELO quadrajet.flashcom.com) (216.200.30.95) by smtp.flashcom.net (209.228.12.67) with SMTP; 23 Jan 2001 01:56:13 -0800 X-Sent: 23 Jan 2001 09:56:13 GMT Received: (from guy@localhost) by quadrajet.flashcom.com (8.9.3/8.9.3) id BAA04898; Tue, 23 Jan 2001 01:56:12 -0800 (PST) (envelope-from gharris) Date: Tue, 23 Jan 2001 01:56:12 -0800 From: Guy Harris To: Neil Brown Cc: Matthias Andree , Linux NFS mailing list , reiserfs-list@namesys.com, FreeBSD Stable Subject: Re: [NFS] Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, ReiserFS Message-ID: <20010123015612.H345@quadrajet.flashcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Beware of error messages reported by tcpdump... they are misleading. > The error code in the tcp packet is an "NFS error code" which should > not be confused with an "Unix-errno" error code, though there are > sometimes similarities. > tcpdump seems to assume that nfs error codes *are* unix error codes. "Fixed in 3.6"; tcpdump 3.6 doesn't assume NFS error codes are errno values for the current host. However, the "116" in the 23:22:29.528764 emma1.nfs > freebsd.526363636: reply ok 116 access ERROR: Read-only file system (ttl 64, id 12889) line isn't the error value, it's the length of the packet; "nfsreply_print()' in tcpdump 3.5 does: if (!nflag) (void)printf("%s.nfs > %s.%u: reply %s %d", ipaddr_string(&ip->ip_src), ipaddr_string(&ip->ip_dst), (u_int32_t)ntohl(rp->rm_xid), ntohl(rp->rm_reply.rp_stat) == MSG_ACCEPTED? "ok":"ERR", length); else (void)printf("%s.%u > %s.%u: reply %s %d", ipaddr_string(&ip->ip_src), NFS_PORT, ipaddr_string(&ip->ip_dst), (u_int32_t)ntohl(rp->rm_xid), ntohl(rp->rm_reply.rp_stat) == MSG_ACCEPTED? "ok":"ERR", length); EROFS is 30 on both Linux/x86 and FreeBSD (and 30 goes, I suspect, all the way back to V6 UNIX or earlier, so I suspect just about any UNIX with AT&T code in it, or even that once upon a time had AT&T code in it, e.g. most of the commercial UNIXes, use 30 for EROFS). So... > So my guess is that the reiserfs code which tries to support nfsd (which > may well involve some patches to knfsd) is having problems, and wants > to return ESTALE, but returns it without converting to an NFS error > code. ..."Read-only file system" probably means you got back EROFS from the server, and the ReiserFS code is probably not to blame - the Linux nfsd in 2.2.18 appears to assume that the underlying file system returns Linux errno values (or the negative of same), and maps them to NFS error values. I note, however, that Solaris's NFS server, as I remember, will, if you make a V3 ACCESS call, asking for ACCESS3_MODIFY and/or ACCESS3_EXTEND (and/or, I suspect, ACCESS3_DELETE), will, if the file being asked about is on a read-only file system, just return access permissions with those bits turned off - RFC 1813 doesn't list NFS3ERR_ROFS as one of the error returns permissible from ACCESS. (I remember this because I saw a note on the "toasters" mailing list, where somebody's Solaris client was trying to write to a file on a NetApp file server when that file was in a snapshot, and those files aren't writable; we returned EROFS to that attempt, and the Solaris client apparently decided "well, maybe he hasn't remounted the file system read/write yet", and just kept trying, to no avail. I figured the underlying problem was that we weren't returning "no, you can't write it" to an ACCESS call, and that, were we to do so, the "open()" of the file would fail, and the Solaris box wouldn't try to write to it in the first place; I sent mail back to the person who sent the note, asking him to try it with a Solaris NFS server, and, sure enough, the Solaris box did, as I remember, what I described above. I filed a bug inside NetApp about this, and our server was fixed to do what the Solaris server does. As the original implementor of V3 on NetApp boxes, I'll cheerfully take the 50 lashes with a wet noodle called for here. :-)) Perhaps the Linux server should, in "nfsd_access()", treat "nfserr_rofs" the same way it treats "nfserr_perm" and "nfserr_acces", and just say the access type is denied but the access query succeeded, doing the same thing that Solaris and a future release of the NetApp software will do. (It looks as if the FreeBSD NFS server already does that - it treats all errors from "nfsrv_access()" as meaning "access denied", not "access call failed", so it treats EROFS in that fashion. The same probably applies to other BSDs.) As for why the V2 client doesn't appear to have this problem, the V2 client doesn't make an ACCESS call, because NFS V2 doesn't have an ACCESS call to make. As for why it's a problem with ReiserFS but not ext2fs, if the ReiserFS file system in question wasn't mounted read-only, perhaps somehow it's bogusly reporting read-onlyness to the NFS server. If it *was* mounted read-only, was the ext2 file system also mounted read-only? If not, that might explain it. As for why it's a problem with the FreeBSD client but not the Solaris client, I'm not sure - a quick look at the 4.2 client code doesn't seem to show any way in which the EROFS is "sticky" to the extent that it affects all client accesses, as it doesn't cache the result of an ACCESS call that failed. It may just be that the Solaris client just ignores NFS3ERR_ROFS from an ACCESS call and does an access check based on the permission bits, rather than returning EROFS, whilst the FreeBSD client returns EROFS; if ReiserFS is returning EROFS bogusly, that might cause the symptoms in question. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message