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 <[email protected]>
"J. Bruce Fields" <[email protected]> writes:
>> > > It's expected. I'd recommend turning off nfsv4 on the server (add "-N4"
>> > > to the rpc.nfsd commandline) for now.
>> >
>> > 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)
>>
>> No, the -N4 tells rpc.mountd to turn off NFSv4 support before starting
>
> (Hah!--trying to correct you, I got it wrong myself--I really did mean
> rpc.*nfsd*, not rpc.mountd.)
Oh, I was reading very old man page. Thanks for correcting.
--
OGAWA Hirofumi <[email protected]>
On Sun, Feb 07, 2010 at 12:32:04PM +0900, OGAWA Hirofumi wrote:
> 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?
It's expected. I'd recommend turning off nfsv4 on the server (add "-N4"
to the rpc.nfsd commandline) for now.
--b.
"J. Bruce Fields" <[email protected]> writes:
>> 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?
>
> It's expected. I'd recommend turning off nfsv4 on the server (add "-N4"
> to the rpc.nfsd commandline) for now.
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 <[email protected]>
On Sun, Feb 07, 2010 at 05:23:49PM +0900, OGAWA Hirofumi wrote:
> "J. Bruce Fields" <[email protected]> writes:
>
> >> 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?
> >
> > It's expected. I'd recommend turning off nfsv4 on the server (add "-N4"
> > to the rpc.nfsd commandline) for now.
>
> This looks like the silent user visible change. So, it would be better
> to add more comment at least in changelog.
Or rather it should be fixed. We should not silently break existing
and probably rather common setups.
>>>>> "Christoph" == Christoph Hellwig <[email protected]> writes:
Christoph> On Sun, Feb 07, 2010 at 05:23:49PM +0900, OGAWA Hirofumi wrote:
>> "J. Bruce Fields" <[email protected]> writes:
>>
>> >> 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?
>> >
>> > It's expected. I'd recommend turning off nfsv4 on the server (add "-N4"
>> > to the rpc.nfsd commandline) for now.
>>
>> This looks like the silent user visible change. So, it would be better
>> to add more comment at least in changelog.
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
On Sun, Feb 07, 2010 at 03:31:03AM -0500, Christoph Hellwig wrote:
> On Sun, Feb 07, 2010 at 05:23:49PM +0900, OGAWA Hirofumi wrote:
> > "J. Bruce Fields" <[email protected]> writes:
> >
> > >> 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?
> > >
> > > It's expected. I'd recommend turning off nfsv4 on the server (add "-N4"
> > > to the rpc.nfsd commandline) for now.
> >
> > This looks like the silent user visible change. So, it would be better
> > to add more comment at least in changelog.
>
> Or rather it should be fixed. We should not silently break existing
> and probably rather common setups.
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.
On Sun, Feb 07, 2010 at 05:23:49PM +0900, OGAWA Hirofumi wrote:
> "J. Bruce Fields" <[email protected]> writes:
>
> >> 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?
> >
> > It's expected. I'd recommend turning off nfsv4 on the server (add "-N4"
> > to the rpc.nfsd commandline) for now.
>
> 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)
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.
On Mon, Feb 08, 2010 at 01:33:43PM -0500, J. Bruce Fields wrote:
> On Sun, Feb 07, 2010 at 05:23:49PM +0900, OGAWA Hirofumi wrote:
> > "J. Bruce Fields" <[email protected]> writes:
> >
> > >> 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?
> > >
> > > It's expected. I'd recommend turning off nfsv4 on the server (add "-N4"
> > > to the rpc.nfsd commandline) for now.
> >
> > 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)
>
> No, the -N4 tells rpc.mountd to turn off NFSv4 support before starting
(Hah!--trying to correct you, I got it wrong myself--I really did mean
rpc.*nfsd*, not rpc.mountd.)
--b.
> 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.