NFSD IPv6 support for 2.6.29

NFSD IPv6 support for 2.6.29

[Chuck Lever]

Hi Aime, Varun-

Bruce asked me to collect server-side IPv6 patches for upstream.  I've  
collected the patches that have been posted on the list, and added  
some fixes of my own.

Can you have a look at

   http://git.linux-nfs.org/?p=cel/cel-2.6.git;a=summary

   tag cel-ipv6-10292008

These have been build tested, but I haven't done any run-time testing  
yet.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFSD IPv6 support for 2.6.29

[Varun Chandramohan]

Chuck Lever wrote:
> Hi Aime, Varun-
>
> Bruce asked me to collect server-side IPv6 patches for upstream.  I've 
> collected the patches that have been posted on the list, and added 
> some fixes of my own.
>
> Can you have a look at
>
>   http://git.linux-nfs.org/?p=cel/cel-2.6.git;a=summary
>
>   tag cel-ipv6-10292008
>
> These have been build tested, but I haven't done any run-time testing 
> yet.
>
> -- 
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
Hi Chuck,
                   It looks ok to me. Aime will be able to confirm 
better. I will do the run-time test and let you know.

Regards,
Varun

Re: NFSD IPv6 support for 2.6.29

[Varun Chandramohan]

Chuck Lever wrote:
> Hi Aime, Varun-
>
> Bruce asked me to collect server-side IPv6 patches for upstream.  I've 
> collected the patches that have been posted on the list, and added 
> some fixes of my own.
>
> Can you have a look at
>
>   http://git.linux-nfs.org/?p=cel/cel-2.6.git;a=summary
>
>   tag cel-ipv6-10292008
>
> These have been build tested, but I haven't done any run-time testing 
> yet.
>
> -- 
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
Hi Chuck,

                 I just realized that i forgot to update you about the 
test result of your tree. I found NFSv4 over ipv6 working well. So it 
can be pulled into the mainline soon.

Thanks

Varun

Re: NFSD IPv6 support for 2.6.29

[Chuck Lever]

On Nov 10, 2008, at 12:15 AM, Varun Chandramohan wrote:

> Chuck Lever wrote:
>> Hi Aime, Varun-
>>
>> Bruce asked me to collect server-side IPv6 patches for upstream.   
>> I've collected the patches that have been posted on the list, and  
>> added some fixes of my own.
>>
>> Can you have a look at
>>
>>  http://git.linux-nfs.org/?p=cel/cel-2.6.git;a=summary
>>
>>  tag cel-ipv6-10292008
>>
>> These have been build tested, but I haven't done any run-time  
>> testing yet.
>>
>> -- 
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
> Hi Chuck,
>
>                I just realized that i forgot to update you about the  
> test result of your tree. I found NFSv4 over ipv6 working well. So  
> it can be pulled into the mainline soon.

Thanks for testing!

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFSD IPv6 support for 2.6.29

[Le Rouzic]

Hi,
Sorry for not answering earlier but I am back to-day after some days ou=
t=20
of my office.
I plan to do also some run-time  testing with your new tree.

Regards



Chuck Lever a =E9crit :

>
> On Nov 10, 2008, at 12:15 AM, Varun Chandramohan wrote:
>
>> Chuck Lever wrote:
>>
>>> Hi Aime, Varun-
>>>
>>> Bruce asked me to collect server-side IPv6 patches for upstream.  =20
>>> I've collected the patches that have been posted on the list, and =20
>>> added some fixes of my own.
>>>
>>> Can you have a look at
>>>
>>>  http://git.linux-nfs.org/?p=3Dcel/cel-2.6.git;a=3Dsummary
>>>
>>>  tag cel-ipv6-10292008
>>>
>>> These have been build tested, but I haven't done any run-time =20
>>> testing yet.
>>>
>>> --=20
>>> Chuck Lever
>>> chuck[dot]lever[at]oracle[dot]com
>>
>> Hi Chuck,
>>
>>                I just realized that i forgot to update you about the=
 =20
>> test result of your tree. I found NFSv4 over ipv6 working well. So =20
>> it can be pulled into the mainline soon.
>
>
> Thanks for testing!
>
> --=20
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
> --=20
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" =
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>


--=20
-----------------------------------------------------------------
Company : Bull, Architect of an Open World TM (www.bull.com)
Name    : Aime Le Rouzic=20
Mail    : Bull - BP 208 - 38432 Echirolles Cedex - France
E-Mail  : aime.le-rouzic@bull.net
Phone   : 33 (4) 76.29.75.51
=46ax     : 33 (4) 76.29.75.18
-----------------------------------------------------------------=20

Re: NFSD IPv6 support for 2.6.29

[Chuck Lever]

On Nov 12, 2008, at 11:02 AM, Le Rouzic wrote:
>
> Hi,
> Sorry for not answering earlier but I am back to-day after some days =
=20
> out
> of my office.
> I plan to do also some run-time  testing with your new tree.

Thanks for testing, and don't be afraid to review the patches too.  :-)

> Regards
>
> Chuck Lever a =E9crit :
>
>>
>> On Nov 10, 2008, at 12:15 AM, Varun Chandramohan wrote:
>>
>>> Chuck Lever wrote:
>>>
>>>> Hi Aime, Varun-
>>>>
>>>> Bruce asked me to collect server-side IPv6 patches for upstream.
>>>> I've collected the patches that have been posted on the list, and
>>>> added some fixes of my own.
>>>>
>>>> Can you have a look at
>>>>
>>>> http://git.linux-nfs.org/?p=3Dcel/cel-2.6.git;a=3Dsummary
>>>>
>>>> tag cel-ipv6-10292008
>>>>
>>>> These have been build tested, but I haven't done any run-time
>>>> testing yet.
>>>>
>>>> --
>>>> Chuck Lever
>>>> chuck[dot]lever[at]oracle[dot]com
>>>
>>> Hi Chuck,
>>>
>>>               I just realized that i forgot to update you about the
>>> test result of your tree. I found NFSv4 over ipv6 working well. So
>>> it can be pulled into the mainline soon.
>>
>>
>> Thanks for testing!
>>
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-=20
>> nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
> --
> -----------------------------------------------------------------
> Company : Bull, Architect of an Open World TM (www.bull.com)
> Name    : Aime Le Rouzic
> Mail    : Bull - BP 208 - 38432 Echirolles Cedex - France
> E-Mail  : aime.le-rouzic@bull.net
> Phone   : 33 (4) 76.29.75.51
> Fax     : 33 (4) 76.29.75.18
> -----------------------------------------------------------------
>

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFSD IPv6 support for 2.6.29

[Le Rouzic]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

Chuck Lever a écrit :

>>> On Nov 10, 2008, at 12:15 AM, Varun Chandramohan wrote:
>>>
>>>> Chuck Lever wrote:
>>>>
>>>>> Hi Aime, Varun-
>>>>>
>>>>> Bruce asked me to collect server-side IPv6 patches for upstream.
>>>>> I've collected the patches that have been posted on the list, and
>>>>> added some fixes of my own.
>>>>>
>>>>> Can you have a look at
>>>>>
>>>>> http://git.linux-nfs.org/?p=cel/cel-2.6.git;a=summary
>>>>>
>>>>> tag cel-ipv6-10292008
>>>>>
>>>>> These have been build tested, but I haven't done any run-time
>>>>> testing yet.
>>>>>
>>>>> -- 
>>>>> Chuck Lever
>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>
>>>>
>>>> Hi Chuck,
>>>>
>>>>               I just realized that i forgot to update you about the
>>>> test result of your tree. I found NFSv4 over ipv6 working well. So
>>>> it can be pulled into the mainline soon.
>>>
 Hi
I have tested the "tag cel-ipv6-10292008" and some robustness tests
started simultaneously (connectathon, fsx, iozone, fss_stress, ffsb) have
been running fine during several hours in IPV6 and IPV4.
I used the my nfs-utils package based on nfs-utils.1.1.2 
(http://nfsv4.bullopensource.org/)

Nevertheless I may have missed something during the last mails about IPV6
but I don't find in your tree changes about IPV6 in fs/nfsd/nfsctl.c

I join the patch I submitted for that.

Best Regards


-- 
-----------------------------------------------------------------
Company : Bull, Architect of an Open World TM (www.bull.com)
Name    : Aime Le Rouzic 
Mail    : Bull - BP 208 - 38432 Echirolles Cedex - France
E-Mail  : aime.le-rouzic@bull.net
Phone   : 33 (4) 76.29.75.51
Fax     : 33 (4) 76.29.75.18
----------------------------------------------------------------- 


[-- Attachment #2: patch_ipv6overrpcbindv4_nfsctl --]
[-- Type: text/plain, Size: 2617 bytes --]


 NFSV4 IPV6: Adds AF_INET6 domain processing when AF_INET processing only available in nfsd/nfsctl.c

 ---

 fs/nfsd/nfsctl.c     |   41 +++++++++++++++++++++++++++++++----------

 Signed-off-by: Aime Le Rouzic <aime.le-rouzic@bull.net>
---
diff -Nru rpcbindv4/fs/nfsd/nfsctl.c ipv6overrpcbindv4/fs/nfsd/nfsctl.c
--- rpcbindv4/fs/nfsd/nfsctl.c	2008-09-15 14:50:09.000000000 +0200
+++ ipv6overrpcbindv4/fs/nfsd/nfsctl.c	2008-09-15 15:18:24.000000000 +0200
@@ -230,6 +230,7 @@
 {
 	struct nfsctl_fsparm *data;
 	struct sockaddr_in *sin;
+	struct sockaddr_in6 *sin6;
 	struct auth_domain *clp;
 	int err = 0;
 	struct knfsd_fh *res;
@@ -239,9 +240,19 @@
 		return -EINVAL;
 	data = (struct nfsctl_fsparm*)buf;
 	err = -EPROTONOSUPPORT;
-	if (data->gd_addr.sa_family != AF_INET)
+	switch (data->gd_addr.sa_family) {
+	case AF_INET:
+		sin = (struct sockaddr_in *)&data->gd_addr;
+		ipv6_addr_set_v4mapped(sin->sin_addr.s_addr, &in6);
+		break;
+	case AF_INET6:
+		sin6 = (struct sockaddr_in6 *)&data->gd_addr;
+		ipv6_addr_copy(&in6, &sin6->sin6_addr); 
+		break;
+	default:
 		goto out;
-	sin = (struct sockaddr_in *)&data->gd_addr;
+	}
+
 	if (data->gd_maxlen > NFS3_FHSIZE)
 		data->gd_maxlen = NFS3_FHSIZE;
 
@@ -249,8 +260,6 @@
 
 	exp_readlock();
 
-	ipv6_addr_set_v4mapped(sin->sin_addr.s_addr, &in6);
-
 	clp = auth_unix_lookup(&in6);
 	if (!clp)
 		err = -EPERM;
@@ -269,6 +278,7 @@
 {
 	struct nfsctl_fdparm *data;
 	struct sockaddr_in *sin;
+	struct sockaddr_in6 *sin6;
 	struct auth_domain *clp;
 	int err = 0;
 	struct knfsd_fh fh;
@@ -279,20 +289,31 @@
 		return -EINVAL;
 	data = (struct nfsctl_fdparm*)buf;
 	err = -EPROTONOSUPPORT;
-	if (data->gd_addr.sa_family != AF_INET)
+	if (data->gd_addr.sa_family != AF_INET &&
+	    data->gd_addr.sa_family != AF_INET6)
 		goto out;
+
 	err = -EINVAL;
 	if (data->gd_version < 2 || data->gd_version > NFSSVC_MAXVERS)
 		goto out;
 
 	res = buf;
-	sin = (struct sockaddr_in *)&data->gd_addr;
 	exp_readlock();
 
-	ipv6_addr_set_v4mapped(sin->sin_addr.s_addr, &in6);
+	switch (data->gd_addr.sa_family) {
+	case AF_INET:
+		sin = (struct sockaddr_in *)&data->gd_addr;
+		ipv6_addr_set_v4mapped(sin->sin_addr.s_addr, &in6);
+		break;
+	case AF_INET6:
+		sin6 = (struct sockaddr_in6 *)&data->gd_addr;
+		ipv6_addr_copy(&in6, &sin6->sin6_addr);
+		break;
+	default:
+		goto out;
+	}
 
-	clp = auth_unix_lookup(&in6);
-	if (!clp)
+	if (!(clp = auth_unix_lookup(&in6)))
 		err = -EPERM;
 	else {
 		err = exp_rootfh(clp, data->gd_path, &fh, NFS_FHSIZE);
@@ -305,7 +326,7 @@
 		memcpy(res, &fh.fh_base, fh.fh_size);
 		err = NFS_FHSIZE;
 	}
- out:
+out:
 	return err;
 }

Re: NFSD IPv6 support for 2.6.29

[Chuck Lever]

On Nov 17, 2008, at Nov 17, 2008, 12:52 PM, Le Rouzic wrote:
> Chuck Lever a =E9crit :
>
>>>> On Nov 10, 2008, at 12:15 AM, Varun Chandramohan wrote:
>>>>
>>>>> Chuck Lever wrote:
>>>>>
>>>>>> Hi Aime, Varun-
>>>>>>
>>>>>> Bruce asked me to collect server-side IPv6 patches for upstream.
>>>>>> I've collected the patches that have been posted on the list, an=
d
>>>>>> added some fixes of my own.
>>>>>>
>>>>>> Can you have a look at
>>>>>>
>>>>>> http://git.linux-nfs.org/?p=3Dcel/cel-2.6.git;a=3Dsummary
>>>>>>
>>>>>> tag cel-ipv6-10292008
>>>>>>
>>>>>> These have been build tested, but I haven't done any run-time
>>>>>> testing yet.
>>>>>>
>>>>>> --
>>>>>> Chuck Lever
>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>
>>>>>
>>>>> Hi Chuck,
>>>>>
>>>>>              I just realized that i forgot to update you about th=
e
>>>>> test result of your tree. I found NFSv4 over ipv6 working well. S=
o
>>>>> it can be pulled into the mainline soon.
>>>>
> Hi
> I have tested the "tag cel-ipv6-10292008" and some robustness tests
> started simultaneously (connectathon, fsx, iozone, fss_stress, ffsb) =
=20
> have
> been running fine during several hours in IPV6 and IPV4.
> I used the my nfs-utils package based on nfs-utils.1.1.2
> (http://nfsv4.bullopensource.org/)

Thanks for the review and testing.

> Nevertheless I may have missed something during the last mails about =
=20
> IPV6
> but I don't find in your tree changes about IPV6 in fs/nfsd/nfsctl.c

> I join the patch I submitted for that.

write_getfs() and write_getfd() use a fixed size field in the down =20
call that is too small for IPv6 addresses.  That field is defined as a =
=20
"struct sockaddr", but that type is meant only to be used for a =20
pointer (as in "struct sockaddr *").  It happens to be the same size =20
as a sockaddr_in, but it is much smaller than an IPv6 address.

The modern preferred interface is /proc/fs/nfsd/filehandle.  See the =20
comments I added in fs/nfsd/nfsctl.c that describe the whole NFSD =20
interface.  As far as I can tell, no changes are needed in =20
write_filehandle() to support IPv6.

> --
> -----------------------------------------------------------------
> Company : Bull, Architect of an Open World TM (www.bull.com)
> Name    : Aime Le Rouzic
> Mail    : Bull - BP 208 - 38432 Echirolles Cedex - France
> E-Mail  : aime.le-rouzic@bull.net
> Phone   : 33 (4) 76.29.75.51
> Fax     : 33 (4) 76.29.75.18
> -----------------------------------------------------------------
>
>
> NFSV4 IPV6: Adds AF_INET6 domain processing when AF_INET processing =20
> only available in nfsd/nfsctl.c
>
> ---
>
> fs/nfsd/nfsctl.c     |   41 +++++++++++++++++++++++++++++++----------
>
> Signed-off-by: Aime Le Rouzic <aime.le-rouzic@bull.net>
> ---
> diff -Nru rpcbindv4/fs/nfsd/nfsctl.c ipv6overrpcbindv4/fs/nfsd/=20
> nfsctl.c
> --- rpcbindv4/fs/nfsd/nfsctl.c	2008-09-15 14:50:09.000000000 +0200
> +++ ipv6overrpcbindv4/fs/nfsd/nfsctl.c	2008-09-15 15:18:24.000000000 =
=20
> +0200
> @@ -230,6 +230,7 @@
> {
> 	struct nfsctl_fsparm *data;
> 	struct sockaddr_in *sin;
> +	struct sockaddr_in6 *sin6;
> 	struct auth_domain *clp;
> 	int err =3D 0;
> 	struct knfsd_fh *res;
> @@ -239,9 +240,19 @@
> 		return -EINVAL;
> 	data =3D (struct nfsctl_fsparm*)buf;
> 	err =3D -EPROTONOSUPPORT;
> -	if (data->gd_addr.sa_family !=3D AF_INET)
> +	switch (data->gd_addr.sa_family) {
> +	case AF_INET:
> +		sin =3D (struct sockaddr_in *)&data->gd_addr;
> +		ipv6_addr_set_v4mapped(sin->sin_addr.s_addr, &in6);
> +		break;
> +	case AF_INET6:
> +		sin6 =3D (struct sockaddr_in6 *)&data->gd_addr;
> +		ipv6_addr_copy(&in6, &sin6->sin6_addr);
> +		break;
> +	default:
> 		goto out;
> -	sin =3D (struct sockaddr_in *)&data->gd_addr;
> +	}
> +
> 	if (data->gd_maxlen > NFS3_FHSIZE)
> 		data->gd_maxlen =3D NFS3_FHSIZE;
>
> @@ -249,8 +260,6 @@
>
> 	exp_readlock();
>
> -	ipv6_addr_set_v4mapped(sin->sin_addr.s_addr, &in6);
> -
> 	clp =3D auth_unix_lookup(&in6);
> 	if (!clp)
> 		err =3D -EPERM;
> @@ -269,6 +278,7 @@
> {
> 	struct nfsctl_fdparm *data;
> 	struct sockaddr_in *sin;
> +	struct sockaddr_in6 *sin6;
> 	struct auth_domain *clp;
> 	int err =3D 0;
> 	struct knfsd_fh fh;
> @@ -279,20 +289,31 @@
> 		return -EINVAL;
> 	data =3D (struct nfsctl_fdparm*)buf;
> 	err =3D -EPROTONOSUPPORT;
> -	if (data->gd_addr.sa_family !=3D AF_INET)
> +	if (data->gd_addr.sa_family !=3D AF_INET &&
> +	    data->gd_addr.sa_family !=3D AF_INET6)
> 		goto out;
> +
> 	err =3D -EINVAL;
> 	if (data->gd_version < 2 || data->gd_version > NFSSVC_MAXVERS)
> 		goto out;
>
> 	res =3D buf;
> -	sin =3D (struct sockaddr_in *)&data->gd_addr;
> 	exp_readlock();
>
> -	ipv6_addr_set_v4mapped(sin->sin_addr.s_addr, &in6);
> +	switch (data->gd_addr.sa_family) {
> +	case AF_INET:
> +		sin =3D (struct sockaddr_in *)&data->gd_addr;
> +		ipv6_addr_set_v4mapped(sin->sin_addr.s_addr, &in6);
> +		break;
> +	case AF_INET6:
> +		sin6 =3D (struct sockaddr_in6 *)&data->gd_addr;
> +		ipv6_addr_copy(&in6, &sin6->sin6_addr);
> +		break;
> +	default:
> +		goto out;
> +	}
>
> -	clp =3D auth_unix_lookup(&in6);
> -	if (!clp)
> +	if (!(clp =3D auth_unix_lookup(&in6)))
> 		err =3D -EPERM;
> 	else {
> 		err =3D exp_rootfh(clp, data->gd_path, &fh, NFS_FHSIZE);
> @@ -305,7 +326,7 @@
> 		memcpy(res, &fh.fh_base, fh.fh_size);
> 		err =3D NFS_FHSIZE;
> 	}
> - out:
> +out:
> 	return err;
> }

--=20
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFSD IPv6 support for 2.6.29

[Le Rouzic]

Chuck Lever a =E9crit :

>>>>>>> Bruce asked me to collect server-side IPv6 patches for upstream=
=2E
>>>>>>> I've collected the patches that have been posted on the list, a=
nd
>>>>>>> added some fixes of my own.
>>>>>>>
>>>>>>> Can you have a look at
>>>>>>>
>>>>>>> http://git.linux-nfs.org/?p=3Dcel/cel-2.6.git;a=3Dsummary
>>>>>>>
>>>>>>> tag cel-ipv6-10292008
>>>>>>>
>>>>>>> These have been build tested, but I haven't done any run-time
>>>>>>> testing yet.
>>>>>>>
>>>>>>> --=20
>>>>>>> Chuck Lever
>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>
>> Hi
>> I have tested the "tag cel-ipv6-10292008" and some robustness tests
>> started simultaneously (connectathon, fsx, iozone, fss_stress, ffsb)=
 =20
>> have
>> been running fine during several hours in IPV6 and IPV4.
>> I used the my nfs-utils package based on nfs-utils.1.1.2
>> (http://nfsv4.bullopensource.org/)
>
    Hi,
    I get an issue with AIX used as client in front of the above=20
snapshot used on a linux server.
   =20
     Doing the following on the AIX side:
   =20
       mount -o vers=3D4 nfs4gb:/ /mnt/nosec
       cd /mnt/nosec
       mkdir rep
       cd rep

       the command "ls" will fail with the follwing error on the AIX si=
de:
     "kern:err|error unix: Client encounters unexpected=20
NFS4ERR_BAD_COOKIE error from server"

      The problem happens with IPV6 and IPV4
     =20
      Best Regards

--=20
-----------------------------------------------------------------
Company : Bull, Architect of an Open World TM (www.bull.com)
Name    : Aime Le Rouzic=20
Mail    : Bull - BP 208 - 38432 Echirolles Cedex - France
E-Mail  : aime.le-rouzic@bull.net
Phone   : 33 (4) 76.29.75.51
=46ax     : 33 (4) 76.29.75.18
-----------------------------------------------------------------=20

Re: NFSD IPv6 support for 2.6.29

[Chuck Lever]

On Dec 9, 2008, at Dec 9, 2008, 7:37 AM, Le Rouzic wrote:
> Chuck Lever a =E9crit :
>
>>>>>>>> Bruce asked me to collect server-side IPv6 patches for =20
>>>>>>>> upstream.
>>>>>>>> I've collected the patches that have been posted on the list, =
=20
>>>>>>>> and
>>>>>>>> added some fixes of my own.
>>>>>>>>
>>>>>>>> Can you have a look at
>>>>>>>>
>>>>>>>> http://git.linux-nfs.org/?p=3Dcel/cel-2.6.git;a=3Dsummary
>>>>>>>>
>>>>>>>> tag cel-ipv6-10292008
>>>>>>>>
>>>>>>>> These have been build tested, but I haven't done any run-time
>>>>>>>> testing yet.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Chuck Lever
>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>
>>> Hi
>>> I have tested the "tag cel-ipv6-10292008" and some robustness tests
>>> started simultaneously (connectathon, fsx, iozone, fss_stress, ffsb=
)
>>> have
>>> been running fine during several hours in IPV6 and IPV4.
>>> I used the my nfs-utils package based on nfs-utils.1.1.2
>>> (http://nfsv4.bullopensource.org/)
>>
>   Hi,
>   I get an issue with AIX used as client in front of the above
> snapshot used on a linux server.
>
>    Doing the following on the AIX side:
>
>      mount -o vers=3D4 nfs4gb:/ /mnt/nosec
>      cd /mnt/nosec
>      mkdir rep
>      cd rep
>
>      the command "ls" will fail with the follwing error on the AIX =20
> side:
>    "kern:err|error unix: Client encounters unexpected
> NFS4ERR_BAD_COOKIE error from server"
>
>     The problem happens with IPV6 and IPV4

This is probably an issue with NFSv4 proper.  Bruce?

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFSD IPv6 support for 2.6.29

[J. Bruce Fields]

On Tue, Dec 09, 2008 at 11:24:46AM -0500, Chuck Lever wrote:
> On Dec 9, 2008, at Dec 9, 2008, 7:37 AM, Le Rouzic wrote:
>> Chuck Lever a =C3=A9crit :
>>
>>>>>>>>> Bruce asked me to collect server-side IPv6 patches for =20
>>>>>>>>> upstream.
>>>>>>>>> I've collected the patches that have been posted on the=20
>>>>>>>>> list, and
>>>>>>>>> added some fixes of my own.
>>>>>>>>>
>>>>>>>>> Can you have a look at
>>>>>>>>>
>>>>>>>>> http://git.linux-nfs.org/?p=3Dcel/cel-2.6.git;a=3Dsummary
>>>>>>>>>
>>>>>>>>> tag cel-ipv6-10292008
>>>>>>>>>
>>>>>>>>> These have been build tested, but I haven't done any run-time
>>>>>>>>> testing yet.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Chuck Lever
>>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>>
>>>> Hi
>>>> I have tested the "tag cel-ipv6-10292008" and some robustness test=
s
>>>> started simultaneously (connectathon, fsx, iozone, fss_stress, ffs=
b)
>>>> have
>>>> been running fine during several hours in IPV6 and IPV4.
>>>> I used the my nfs-utils package based on nfs-utils.1.1.2
>>>> (http://nfsv4.bullopensource.org/)
>>>
>>   Hi,
>>   I get an issue with AIX used as client in front of the above
>> snapshot used on a linux server.
>>
>>    Doing the following on the AIX side:
>>
>>      mount -o vers=3D4 nfs4gb:/ /mnt/nosec
>>      cd /mnt/nosec
>>      mkdir rep
>>      cd rep
>>
>>      the command "ls" will fail with the follwing error on the AIX =20
>> side:
>>    "kern:err|error unix: Client encounters unexpected
>> NFS4ERR_BAD_COOKIE error from server"
>>
>>     The problem happens with IPV6 and IPV4
>
> This is probably an issue with NFSv4 proper.  Bruce?

Somebody needs to look at a network trace of the above commands, and
find the request that got the BAD_COOKIE return.  It should be to a
readdir request.  Check whether the cookie the client provides in that
request was in fact returned from a previous readdir--if so, this is
probably a server bug, if not, probably a client bug.

Also note there's known problems between an AIX client an linux NFSv4
server when the exported filesystem is ext2 or ext3; xfs, for example,
should work.  (The problem is inadequate ctime resolution on ext2 and
ext3).

--b.

Re: NFSD IPv6 support for 2.6.29

[Le Rouzic]

[-- Attachment #1: Type: text/plain, Size: 3240 bytes --]

J. Bruce Fields a écrit :

>On Tue, Dec 09, 2008 at 11:24:46AM -0500, Chuck Lever wrote:
>  
>
>>On Dec 9, 2008, at Dec 9, 2008, 7:37 AM, Le Rouzic wrote:
>>    
>>
>>>Chuck Lever a écrit :
>>>
>>>      
>>>
>>>>>>>>>>Bruce asked me to collect server-side IPv6 patches for  
>>>>>>>>>>upstream.
>>>>>>>>>>I've collected the patches that have been posted on the 
>>>>>>>>>>list, and
>>>>>>>>>>added some fixes of my own.
>>>>>>>>>>
>>>>>>>>>>Can you have a look at
>>>>>>>>>>
>>>>>>>>>>http://git.linux-nfs.org/?p=cel/cel-2.6.git;a=summary
>>>>>>>>>>
>>>>>>>>>>tag cel-ipv6-10292008
>>>>>>>>>>
>>>>>>>>>>These have been build tested, but I haven't done any run-time
>>>>>>>>>>testing yet.
>>>>>>>>>>
>>>>>>>>>>--
>>>>>>>>>>Chuck Lever
>>>>>>>>>>chuck[dot]lever[at]oracle[dot]com
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>Hi
>>>>>I have tested the "tag cel-ipv6-10292008" and some robustness tests
>>>>>started simultaneously (connectathon, fsx, iozone, fss_stress, ffsb)
>>>>>have
>>>>>been running fine during several hours in IPV6 and IPV4.
>>>>>I used the my nfs-utils package based on nfs-utils.1.1.2
>>>>>(http://nfsv4.bullopensource.org/)
>>>>>          
>>>>>
>>>  Hi,
>>>  I get an issue with AIX used as client in front of the above
>>>snapshot used on a linux server.
>>>
>>>   Doing the following on the AIX side:
>>>
>>>     mount -o vers=4 nfs4gb:/ /mnt/nosec
>>>     cd /mnt/nosec
>>>     mkdir rep
>>>     cd rep
>>>
>>>     the command "ls" will fail with the follwing error on the AIX  
>>>side:
>>>   "kern:err|error unix: Client encounters unexpected
>>>NFS4ERR_BAD_COOKIE error from server"
>>>
>>>    The problem happens with IPV6 and IPV4
>>>      
>>>
>>This is probably an issue with NFSv4 proper.  Bruce?
>>    
>>
>
>Somebody needs to look at a network trace of the above commands, and
>find the request that got the BAD_COOKIE return.  It should be to a
>readdir request.  Check whether the cookie the client provides in that
>request was in fact returned from a previous readdir--if so, this is
>probably a server bug, if not, probably a client bug.
>
>Also note there's known problems between an AIX client an linux NFSv4
>server when the exported filesystem is ext2 or ext3; xfs, for example,
>should work.  (The problem is inadequate ctime resolution on ext2 and
>ext3).
>
>--b.
>  
>
  Hi,
  I joined at this mail two wireshark traces. One when it was working 
(trace_2.6.27-rc3)
  and the other one with the error(trace_2.6.28-rc2).
  It looks to come because the operation NVERIFY which was returned 
NFS_OK before
  now returns NFS4ERR_SAME making AIX retrying the readdir with an 
incremented cookie .
 
  Cheers

>--
>To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>  
>


-- 
-----------------------------------------------------------------
Company : Bull, Architect of an Open World TM (www.bull.com)
Name    : Aime Le Rouzic 
Mail    : Bull - BP 208 - 38432 Echirolles Cedex - France
E-Mail  : aime.le-rouzic@bull.net
Phone   : 33 (4) 76.29.75.51
Fax     : 33 (4) 76.29.75.18
----------------------------------------------------------------- 


[-- Attachment #2: trace_2.6.27-rc3 --]
[-- Type: application/octet-stream, Size: 9518 bytes --]

[-- Attachment #3: trace_2.6.28-rc2 --]
[-- Type: application/octet-stream, Size: 8450 bytes --]

Re: NFSD IPv6 support for 2.6.29

[Trond Myklebust]

On Wed, 2008-12-10 at 15:48 +0100, Le Rouzic wrote:

>   Hi,
>   I joined at this mail two wireshark traces. One when it was working 
> (trace_2.6.27-rc3)
>   and the other one with the error(trace_2.6.28-rc2).
>   It looks to come because the operation NVERIFY which was returned 
> NFS_OK before
>   now returns NFS4ERR_SAME making AIX retrying the readdir with an 
> incremented cookie .

While there may be a server bug here, it definitely is wrong for the AIX
client to be sending a READDIR request with a cookie argument of '1'.
RFC3530 is adamant that

        For READDIR arguments, cookie values of 1 and 2 should not be
        used and for READDIR results cookie values of 0, 1, and 2 should
        not be returned.

That said, I'd love to understand why the server replied to the first
READDIR request with no entries, and yet with EOF not set. Is it perhaps
because the 'dircount' was too small, Bruce?

Cheers
  Trond

Re: NFSD IPv6 support for 2.6.29

[J. Bruce Fields]

On Wed, Dec 10, 2008 at 10:04:45AM -0500, Trond Myklebust wrote:
> On Wed, 2008-12-10 at 15:48 +0100, Le Rouzic wrote:
> 
> >   Hi,
> >   I joined at this mail two wireshark traces. One when it was working 
> > (trace_2.6.27-rc3)
> >   and the other one with the error(trace_2.6.28-rc2).
> >   It looks to come because the operation NVERIFY which was returned 
> > NFS_OK before
> >   now returns NFS4ERR_SAME making AIX retrying the readdir with an 
> > incremented cookie .
> 
> While there may be a server bug here, it definitely is wrong for the AIX
> client to be sending a READDIR request with a cookie argument of '1'.
> RFC3530 is adamant that
> 
>         For READDIR arguments, cookie values of 1 and 2 should not be
>         used and for READDIR results cookie values of 0, 1, and 2 should
>         not be returned.
> 
> That said, I'd love to understand why the server replied to the first
> READDIR request with no entries, and yet with EOF not set. Is it perhaps
> because the 'dircount' was too small, Bruce?

Oops, my bad--mention of readdir should have reminded me of commit
b726e923ea4d216027e466aa602d914e4b4a63af "Fix nfsd truncation of readdir
results", which fixed a problem like that; that went into -rc4, so worth
retesting with -rc4.

Also, spurious NFS4ERR_SAME calls are a symptom of the ctime resolution
problem so worth retrying with a different filesystem with you're using
ext2/3.

--b.