[PATCH] nfs: fix encode_fsinfo_maxsz

[PATCH] nfs: fix encode_fsinfo_maxsz

[Benny Halevy]

From: Fred Isaman <iisaman@citi.umich.edu>

The previous value was not taking into account space for bitmap array size.

Signed-off-by: Fred Isaman <iisaman@citi.umich.edu>
Signed-off-by: Benny Halevy <bhalevy@panasas.com>
---
 fs/nfs/nfs4xdr.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
index 51dd380..0277821 100644
--- a/fs/nfs/nfs4xdr.c
+++ b/fs/nfs/nfs4xdr.c
@@ -110,7 +110,7 @@ static int nfs4_stat_to_errno(int);
 #define decode_savefh_maxsz     (op_decode_hdr_maxsz)
 #define encode_restorefh_maxsz  (op_encode_hdr_maxsz)
 #define decode_restorefh_maxsz  (op_decode_hdr_maxsz)
-#define encode_fsinfo_maxsz	(op_encode_hdr_maxsz + 2)
+#define encode_fsinfo_maxsz	(encode_getattr_maxsz)
 #define decode_fsinfo_maxsz	(op_decode_hdr_maxsz + 11)
 #define encode_renew_maxsz	(op_encode_hdr_maxsz + 3)
 #define decode_renew_maxsz	(op_decode_hdr_maxsz)
-- 
1.5.3.3

nfs over ipv6 support

[Rajesham Gajjela]

Did any body test nfs (v2 and v3) over ipv6 ?
do you guys claim "this feature suppose to work" ?

It did not work for me. Here are the details of
experiments I did (for me server and client is
same):
 
1) Kernel side : Linux-2.6.12-5 +
      linux-2.6.12-rc6-CITI_NFS4_ALL-1.dif +
      Chuck Lever Transport Patch
(http://oss.oracle.com/~cel/linux-2.6/2.6.12/release-notes.html)

2) User land (tools) side: libtirpc-0.1.7-1 + 
     rpcbind-0.1.4 + nfs-utils-1.1.1 + quota-3.12-5
(Ref:
http://nfsv4.bullopensource.org/patches/nfsv4_ipv6-2)

3) rpcbind suppose to recognize ipv6/ipv4 tcp/udp 
   protocols (after modifying /etc/netconfig). I did 
   softlink of /usr/bin/rpcbind to /sbin/portmap).
   Then did "service portmap restart".
   Then "service nfs restart". NFS services failed.

syslog messages:

Mar 13 19:32:20 DXi5500-12345 nfs: Starting NFS
services:  succeeded
Mar 13 19:32:20 DXi5500-12345 nfs: rpc.rquotad startup
succeeded
Mar 13 19:32:20 DXi5500-12345 kernel: RPC: transport
(2/17) not supported
Mar 13 19:32:20 DXi5500-12345 last message repeated 2
times
Mar 13 19:32:20 DXi5500-12345 nfsd[12453]: nfssvc:
Input/output error
Mar 13 19:32:20 DXi5500-12345 nfs: rpc.nfsd startup
failed
Mar 13 19:32:20 DXi5500-12345 nfs: rpc.mountd startup
succeeded
Mar 13 19:32:20 DXi5500-12345 rpc.idmapd: nfsdreopen:
Opening '/proc/net/rpc/nfs4.idtoname/channel' failed:
errno 2 (No such file or directory)
Mar 13 19:32:20 DXi5500-12345 rpc.idmapd: nfsdreopen:
Opening '/proc/net/rpc/nfs4.nametoid/channel' failed:
errno 2 (No such file or directory)
Mar 13 19:32:20 DXi5500-12345 rpcidmapd: rpc.idmapd
-SIGHUP succeeded



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: [PATCH] nfs: fix encode_fsinfo_maxsz

[Trond Myklebust]

On Thu, 2008-03-13 at 15:26 +0200, Benny Halevy wrote:
> From: Fred Isaman <iisaman@citi.umich.edu>
> 
> The previous value was not taking into account space for bitmap array size.
> 
> Signed-off-by: Fred Isaman <iisaman@citi.umich.edu>
> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
> ---
>  fs/nfs/nfs4xdr.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
> index 51dd380..0277821 100644
> --- a/fs/nfs/nfs4xdr.c
> +++ b/fs/nfs/nfs4xdr.c
> @@ -110,7 +110,7 @@ static int nfs4_stat_to_errno(int);
>  #define decode_savefh_maxsz     (op_decode_hdr_maxsz)
>  #define encode_restorefh_maxsz  (op_encode_hdr_maxsz)
>  #define decode_restorefh_maxsz  (op_decode_hdr_maxsz)
> -#define encode_fsinfo_maxsz	(op_encode_hdr_maxsz + 2)
> +#define encode_fsinfo_maxsz	(encode_getattr_maxsz)
>  #define decode_fsinfo_maxsz	(op_decode_hdr_maxsz + 11)
>  #define encode_renew_maxsz	(op_encode_hdr_maxsz + 3)
>  #define decode_renew_maxsz	(op_decode_hdr_maxsz)

Thanks!

Has this ever been observed to cause problems in the mainline NFSv4?
Having never seen any such problems myself, I'm a bit inclined to delay
this until the 2.6.26 merge window. That said, if you can point to an
instance where it caused a bug, then I'll push it to Linus sooner.

Cheers
  Trond

Re: [PATCH] nfs: fix encode_fsinfo_maxsz

[Benny Halevy]

Trond Myklebust wrote:
> On Thu, 2008-03-13 at 15:26 +0200, Benny Halevy wrote:
>> From: Fred Isaman <iisaman@citi.umich.edu>
>>
>> The previous value was not taking into account space for bitmap array size.
>>
>> Signed-off-by: Fred Isaman <iisaman@citi.umich.edu>
>> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
>> ---
>>  fs/nfs/nfs4xdr.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
>> index 51dd380..0277821 100644
>> --- a/fs/nfs/nfs4xdr.c
>> +++ b/fs/nfs/nfs4xdr.c
>> @@ -110,7 +110,7 @@ static int nfs4_stat_to_errno(int);
>>  #define decode_savefh_maxsz     (op_decode_hdr_maxsz)
>>  #define encode_restorefh_maxsz  (op_encode_hdr_maxsz)
>>  #define decode_restorefh_maxsz  (op_decode_hdr_maxsz)
>> -#define encode_fsinfo_maxsz	(op_encode_hdr_maxsz + 2)
>> +#define encode_fsinfo_maxsz	(encode_getattr_maxsz)
>>  #define decode_fsinfo_maxsz	(op_decode_hdr_maxsz + 11)
>>  #define encode_renew_maxsz	(op_encode_hdr_maxsz + 3)
>>  #define decode_renew_maxsz	(op_decode_hdr_maxsz)
> 
> Thanks!
> 
> Has this ever been observed to cause problems in the mainline NFSv4?
> Having never seen any such problems myself, I'm a bit inclined to delay
> this until the 2.6.26 merge window. That said, if you can point to an
> instance where it caused a bug, then I'll push it to Linus sooner.

I can't point to such an instance.
I *think* it was found by code inspection only.
Maybe Fred can...

Benny

> 
> Cheers
>   Trond
> 

Re: [PATCH] nfs: fix encode_fsinfo_maxsz

[Fredric Isaman]

On Thu, 13 Mar 2008, Trond Myklebust wrote:

>
> On Thu, 2008-03-13 at 15:26 +0200, Benny Halevy wrote:
>> From: Fred Isaman <iisaman@citi.umich.edu>
>>
>> The previous value was not taking into account space for bitmap array size.
>>
>> Signed-off-by: Fred Isaman <iisaman@citi.umich.edu>
>> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
>> ---
>>  fs/nfs/nfs4xdr.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
>> index 51dd380..0277821 100644
>> --- a/fs/nfs/nfs4xdr.c
>> +++ b/fs/nfs/nfs4xdr.c
>> @@ -110,7 +110,7 @@ static int nfs4_stat_to_errno(int);
>>  #define decode_savefh_maxsz     (op_decode_hdr_maxsz)
>>  #define encode_restorefh_maxsz  (op_encode_hdr_maxsz)
>>  #define decode_restorefh_maxsz  (op_decode_hdr_maxsz)
>> -#define encode_fsinfo_maxsz	(op_encode_hdr_maxsz + 2)
>> +#define encode_fsinfo_maxsz	(encode_getattr_maxsz)
>>  #define decode_fsinfo_maxsz	(op_decode_hdr_maxsz + 11)
>>  #define encode_renew_maxsz	(op_encode_hdr_maxsz + 3)
>>  #define decode_renew_maxsz	(op_decode_hdr_maxsz)
>
> Thanks!
>
> Has this ever been observed to cause problems in the mainline NFSv4?
> Having never seen any such problems myself, I'm a bit inclined to delay
> this until the 2.6.26 merge window. That said, if you can point to an
> instance where it caused a bug, then I'll push it to Linus sooner.
>
> Cheers
>  Trond
>
>

I just noticed it in the process of adding some attributes to fsinfo, as 
opposed to searching down a bug.

 	Fred

Re: [PATCH] nfs: fix encode_fsinfo_maxsz

[Trond Myklebust]

On Thu, 2008-03-13 at 12:29 -0400, Fredric Isaman wrote:
> 
> On Thu, 13 Mar 2008, Trond Myklebust wrote:
> > Has this ever been observed to cause problems in the mainline NFSv4?
> > Having never seen any such problems myself, I'm a bit inclined to delay
> > this until the 2.6.26 merge window. That said, if you can point to an
> > instance where it caused a bug, then I'll push it to Linus sooner.
> >
> > Cheers
> >  Trond
> >
> >
> 
> I just noticed it in the process of adding some attributes to fsinfo, as 
> opposed to searching down a bug.

OK. I'll queue it up for 2.6.26, then.

Again thanks!

  Trond