Hi,

I've recently noticed I couldn't mount nfs on 2.6.33-rc6. The environment is

	server (nfsd-v3, 2.6.33-rc6) <-> client (2.6.32.7, nfs-utils 1.2.1)

And mount command is

	# mount server:/path /mntpoint

(i.e. without any options. If I specified "vers=3" option, it works).

With some debugging, it seems to change of the error code on nfsd - the
log of failure is the following.

nfsd_dispatch: vers 4 proc 0
nfsd_dispatch: vers 4 proc 1
nfsv4 compound op #1/3: 24 (OP_PUTROOTFH)
nfsv4 compound op ffff88012d9e10c0 opcnt 3 #1: 24: status 30000
nfsv4 compound returned 30000
nfsd: Dropping request; may be revisited later
found domain *.xxx.xx
found fsidtype 1
found fsid length 4
Path seems to be <>
nfsd_dispatch: vers 4 proc 1
nfsv4 compound op #1/3: 24 (OP_PUTROOTFH)
nfsv4 compound op ffff88012dab6228 opcnt 3 #1: 24: status 10006
nfsv4 compound returned 10006

On the older kernel (2.6.32.7), it seems to fallback to nfsv3,

nfsd_dispatch: vers 4 proc 0
nfsd_dispatch: vers 4 proc 1
nfsv4 compound op #1/3: 24 (OP_PUTROOTFH)
nfsv4 compound op d9c04850 opcnt 3 #1: 24: status 2
nfsv4 compound returned 2
nfsd_dispatch: vers 3 proc 0
[...]


And the following commit seems to change the behavior.

[nfsd4: fix error return when pseudoroot missing]
f39bde24b275ddc45df1ed835725b609e178c7a0

Well, anyway, is this a expected behavior change, or something bug?

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
--

[ message continues ]

It's expected.  I'd recommend turning off nfsv4 on the server (add "-N4"
to the rpc.nfsd commandline) for now.

--b.
--

[ message continues ]

This looks like the silent user visible change. So, it would be better
to add more comment at least in changelog.

Well, anyway, thanks. (BTW, I assumed rpc.nfsd is typo of rpc.mountd)
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
--

[ message continues ]

Or rather it should be fixed.  We should not silently break existing
and probably rather common setups.

--

[ message continues ]

>>>>> "Christoph" == Christoph Hellwig <hch@infradead.org> writes:


Christoph> Or rather it should be fixed.  We should not silently break existing
Christoph> and probably rather common setups.

Hear hear!  NFS should just gracefully fall back as far as it can.  A
slow mount is better than NO mount.  Esp when /home is mounted via
NFS.

John
--

[ message continues ]

It's really a bug that we're returning an error at all from this point
in the code, so the new client mount code includes a workaround for this
case, added with the code that attempts v4 first by default.

The error we're returning was also wrong.  Unfortunately, my patch to
fix the error went in at around the same time the new mount code went
into nfs-utils, and we communicated poorly about the change.

So:
	- I'm reverting the server patch.  I'd like to reinstate it
	  eventually, depending on how widespread the new mount code
	  was.
	- We'll also make the mount workaround more robust.
	- Most importantly, we need to stamp out the cases where the
	  server hits this error.

--b.
--

[ message continues ]

No, the -N4 tells rpc.mountd to turn off NFSv4 support before starting
the server.

The problem is that the server is accepting NFSv4 rpc calls even though
it doesn't actually support v4, so the mount fails a few rpc's later
with an odd error.

I changed that error around the same time "mount" on the client was
modified to start trying v4 support first, and the mount code included a
workaround for the linux server behavior that only handled exactly the
old errors.

--b.
--

[ message continues ]

(Hah!--trying to correct you, I got it wrong myself--I really did mean
rpc.*nfsd*, not rpc.mountd.)

--

[ message continues ]

Oh, I was reading very old man page. Thanks for correcting.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
--

[ message continues ]