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
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
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 <[email protected]>
---
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;
}
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 (http://www.bull.com)
> Name : Aime Le Rouzic
> Mail : Bull - BP 208 - 38432 Echirolles Cedex - France
> E-Mail : [email protected]
> 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 <[email protected]>
> ---
> 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
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--=20
-----------------------------------------------------------------
Company : Bull, Architect of an Open World TM (http://www.bull.com)
Name : Aime Le Rouzic=20
Mail : Bull - BP 208 - 38432 Echirolles Cedex - France
E-Mail : [email protected]
Phone : 33 (4) 76.29.75.51
=46ax : 33 (4) 76.29.75.18
-----------------------------------------------------------------=20
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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
> --
> -----------------------------------------------------------------
> Company : Bull, Architect of an Open World TM (http://www.bull.com)
> Name : Aime Le Rouzic
> Mail : Bull - BP 208 - 38432 Echirolles Cedex - France
> E-Mail : [email protected]
> Phone : 33 (4) 76.29.75.51
> Fax : 33 (4) 76.29.75.18
> -----------------------------------------------------------------
>
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
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
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 (http://www.bull.com)
Name : Aime Le Rouzic=20
Mail : Bull - BP 208 - 38432 Echirolles Cedex - France
E-Mail : [email protected]
Phone : 33 (4) 76.29.75.51
=46ax : 33 (4) 76.29.75.18
-----------------------------------------------------------------=20
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
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.
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 [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
>
--
-----------------------------------------------------------------
Company : Bull, Architect of an Open World TM (http://www.bull.com)
Name : Aime Le Rouzic
Mail : Bull - BP 208 - 38432 Echirolles Cedex - France
E-Mail : [email protected]
Phone : 33 (4) 76.29.75.51
Fax : 33 (4) 76.29.75.18
-----------------------------------------------------------------
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
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.