[lkml]   [2003]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [NFS] attempt to use V1 mount protocol on V3 server
On Thu, 04 Sep 2003 01:40:13 +0200, you wrote in linux.kernel:

> a) Is a feature of the 'mount' program. An NFS server should in any
> case not rely on the umount being sent: a client may have crashed
> or been firewalled, or whatever...

Okay. I'm not relying on it, anyway. I had just expected to get a V3
umount call and not a V1 umount call. I could understand the V1 as a
fallback. Seems I have to live with user-space tools calling me for
protocol versions I didn't even register with the portmapper.

> b) Is a kernel feature which will never trigger if you are passing a
> correct filehandle from your mountd.

That's assuming all NFSv3 servers do NFSv2 also. I don't. In this case
the bug was in my nfsd who was not recognizing the filehandle coming in
via GETATTR as correct. ;)

So I'll have to live with registering for V1 also and handling umount
there and rejecting mount with an error. Oh well.

Thanks for the explanations!

Oh, BTW, that reminds me: the 2.6.0-test NFS client does not like
FSSTAT returning NFS3ERR_NOTSUPP. When I started coding, I got a hard
lockup of my system due to that, had to press the reset button, not
even Alt-SysRq wanted to work. I couldn't capture the output and
shutting down the system didn't work, plus I could not start any new
processes. Sure, that was a buggy server, but should that lock up
the kernel? Known problem?

I can probably reproduce that since changing my code to return NOTSUPP
again would be easy, if you are interested.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:48    [W:0.031 / U:23.044 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site