Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Jan 2001 03:04:54 -0800
From:      Mike Smith <msmith@freebsd.org>
To:        Guy Harris <gharris@flashcom.net>
Cc:        Matthias Andree <ma@dt.e-technik.uni-dortmund.de>, 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:  <200101241104.f0OB4sS10071@mass.dis.org>
In-Reply-To: Your message of "Wed, 24 Jan 2001 00:17:01 PST." <20010124001701.F344@quadrajet.flashcom.com> 

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.

I'm not sure that the v3 specification actually cares about telling the 
client "why", and if it did, it should probably have defined it.  I'm not 
really happy that an ACCESS operation should ever return EROFS; the 
operation itself doesn't attempt to write anything to the filesystem.

> 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).

This would be more or less what I'd expect.  From the client's point of 
view, returning "this is a read-only filesystem" is not very useful 
anyway.  What's a read-only filesystem?  The NFS mount?  The filesystem 
backing the mount?

> 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 still don't really understand why the Linux code would return EROFS; we 
send READ|MODIFY|EXTEND|EXECUTE|DELETE|LOOKUP.  If the filesystem is 
read-only, we'd expect to see READ|EXECUTE|LOOKUP (at most) come back, 
but with an OK response.

> 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:

I believe, from discussions with you and Brian when I was doing this 
before, that Solaris does track just the questions that we asked.  
Because I didn't really have anywhere to remember what had been asked, I 
just went ahead and asked for everything.

> 	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 sounds about right.  I'd argue that the Linux server is probably in 
error, but the "easy" solution here will simply be to discard EROFS as 
"No means Yes for Linux", since it's a nonsense response to the query.

(For those following this, see attached diff.  Test results would be 
 appreciated.)

> 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).

Turning the access cache off will significantly increase wire traffic and 
harm your NFS v3 performance a lot.  I'd ask the plaintiff to test the 
attached patch and let me know how it goes; if it seems to avoid the 
problem, I'll go ahead and bring it in.

In the meantime, I'd also ask the Linux NFS maintainers (if they're 
listening) to consider altering their server's behaviour just for the 
sake of correctness (if it hasn't already been done subsequent to this 
relatively ancient release).

Regards,
Mike

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E




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?200101241104.f0OB4sS10071>