_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2007-03-05 at 15:35 -0500, Steve Dickson wrote:
> Over the last new months, I've been getting beaten up
> about the fact the Fedora Core clients (FC5 and FC6)
> no loner works with Tru64 server. The problem is
> accessing mounted directories would fail with -ENOTDIR.
> Similar to:
>
> # ls /mnt/alpha/doc
> /bin/ls: cannot open directory /mnt/alpha/doc: Not a directory
>
> After months of floundering around looking at ethereal
> traces and such, I actually was able to trace down a
> Tru64 server to test against (thanks you very much HP!).
>
> Low and behold... it turns not to be a Linux client
> bug at all... but only Linux clients failed because
> they seem to actually care what fsids are being returned.
>
> The problem is this: Tru64 server exporting Advfs fileystems
> return sign extend fsids in most but not all NFS procedures.
>
> Meaning most fattrs returned by the server have a fsid of:
> fsid: 0xffffffff8419f8d5
>
> but in some procs (like READDIRPLUS) the fsid is
> fsid: 0x000000008419f8d5
>
> Which is _clearly_ wrong and does not happen with UFS
> exports on the same server.
>
> So its my contention that Tru64 has been broken forever
> since only Linux clients fail, which started due to the
> following patch that went into 2.6.12:
Sorry, but I really do not like the idea of fixing server bugs in the
Linux client, and particularly not in generic code like this.
As far as I understood, this was a direct consequence of using the
32bitclients export option to work around the old issues with 64-bit
cookies on readdir. Is there really a need for this option now that
we've ensured that readdir cookies are no longer exported to userland?
Cheers
Trond
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Trond Myklebust wrote:
> On Mon, 2007-03-05 at 15:35 -0500, Steve Dickson wrote:
>
>> Over the last new months, I've been getting beaten up
>> about the fact the Fedora Core clients (FC5 and FC6)
>> no loner works with Tru64 server. The problem is
>> accessing mounted directories would fail with -ENOTDIR.
>> Similar to:
>>
>> # ls /mnt/alpha/doc
>> /bin/ls: cannot open directory /mnt/alpha/doc: Not a directory
>>
>> After months of floundering around looking at ethereal
>> traces and such, I actually was able to trace down a
>> Tru64 server to test against (thanks you very much HP!).
>>
>> Low and behold... it turns not to be a Linux client
>> bug at all... but only Linux clients failed because
>> they seem to actually care what fsids are being returned.
>>
>> The problem is this: Tru64 server exporting Advfs fileystems
>> return sign extend fsids in most but not all NFS procedures.
>>
>> Meaning most fattrs returned by the server have a fsid of:
>> fsid: 0xffffffff8419f8d5
>>
>> but in some procs (like READDIRPLUS) the fsid is
>> fsid: 0x000000008419f8d5
>>
>> Which is _clearly_ wrong and does not happen with UFS
>> exports on the same server.
>>
>> So its my contention that Tru64 has been broken forever
>> since only Linux clients fail, which started due to the
>> following patch that went into 2.6.12:
>>
>
> Sorry, but I really do not like the idea of fixing server bugs in the
> Linux client, and particularly not in generic code like this.
>
> As far as I understood, this was a direct consequence of using the
> 32bitclients export option to work around the old issues with 64-bit
> cookies on readdir. Is there really a need for this option now that
> we've ensured that readdir cookies are no longer exported to userland?
Just to be clear, you are proposing to remove the "32bitclients"
export option from the export options on the deployed Tru64 server?
A potential issue that I could see would be if there are other NFS
clients, who do need that export option used in order to interoperate
with this server.
It is an ickey idea and the right way is to fix the Tru64 server, but
given that we probably can't get it fixed, this seems relatively low
risk.
It also wouldn't be the first time (or last probably :-) ) that we've
worked around a bug in another implementation that should rightly
have been fixed in that other implementation. :-)
ps
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2007-03-05 at 16:46 -0500, Peter Staubach wrote:
> It is an ickey idea and the right way is to fix the Tru64 server, but
> given that we probably can't get it fixed, this seems relatively low
> risk.
I disagree. The fact that people are using the fsid in creative ways, is
reason enough to be cautious about quick fixes. If we really must work
around on the client, then I'd prefer something like a mount option that
just causes us to ignore fsid changes (i.e. fall back to the 2.4.x
behaviour).
Hacking the fsid on behalf of the server is certainly vetoed.
Cheers
Trond
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Trond Myklebust wrote:
> On Mon, 2007-03-05 at 16:46 -0500, Peter Staubach wrote:
>
>> It is an ickey idea and the right way is to fix the Tru64 server, but
>> given that we probably can't get it fixed, this seems relatively low
>> risk.
>>
>
> I disagree. The fact that people are using the fsid in creative ways, is
> reason enough to be cautious about quick fixes. If we really must work
> around on the client, then I'd prefer something like a mount option that
> just causes us to ignore fsid changes (i.e. fall back to the 2.4.x
> behaviour).
>
> Hacking the fsid on behalf of the server is certainly vetoed.
Well, I find it a little hard to imagine that anyone would choose
a combination of fsids which would cause this to do the wrong thing,
but okay. It is definitely a heuristic and thus, subject to possible
failure, no matter how remote.
Perhaps the right thing to do is to revert the NFSv2/NFSv3 support
completely and not have them worry about changing fsids? The common
practice is to use an automounting facility or static mounts to
construct namespaces for NFSv2/NFSv3 networks. It is really only
with the advent of NFSv4 that the fsids actually become interesting
and something that the client needs to be aware of.
Or we could just punt and document that READDIRPLUS must be disabled
on all Tru64 NFS servers if this problem is seen.
Thanx...
ps
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2007-03-05 at 17:22 -0500, Peter Staubach wrote:
> Perhaps the right thing to do is to revert the NFSv2/NFSv3 support
> completely and not have them worry about changing fsids? The common
> practice is to use an automounting facility or static mounts to
> construct namespaces for NFSv2/NFSv3 networks. It is really only
> with the advent of NFSv4 that the fsids actually become interesting
> and something that the client needs to be aware of.
That is not quite true. It has been a problem on NFSv2/v3 ever since
IRIX introduced the 'nohide' export option (which was later copied by
the Linux server). There are only too many programs out there that are
easily fooled by the combination of hard links and non-unique inode
numbers.
> Or we could just punt and document that READDIRPLUS must be disabled
> on all Tru64 NFS servers if this problem is seen.
That would also be an option.
Cheers
Trond
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Trond Myklebust wrote:
> On Mon, 2007-03-05 at 17:22 -0500, Peter Staubach wrote:
>> Or we could just punt and document that READDIRPLUS must be disabled
>> on all Tru64 NFS servers if this problem is seen.
>
> That would also be an option.
Assuming there is a way to turn off READDIRPLUS on the
server side... I'll look into it... Or are you suggesting
that we have a mount option to turn off READDIRPLUS on the
client side? (Note: I believe other implementations have
this mount option if that means anything)....
steved.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
The current code already supports disabling READDIRPLUS to
servers that don't support it. It happens after the first bad
response. The intentional option is a good idea for other
reasons though, huge directories yield huge attributes.
One problem I see with the mount option is that it might be
silently ignored by old mount binaries. That will confuse users
who install a new kernel and don't update util-linux/nfs-utils.
Tom.
At 04:42 PM 3/6/2007, Steve Dickson wrote:
>
>
>Steve Dickson wrote:
>>
>> Trond Myklebust wrote:
>>> On Mon, 2007-03-05 at 17:22 -0500, Peter Staubach wrote:
>>>> Or we could just punt and document that READDIRPLUS must be disabled
>>>> on all Tru64 NFS servers if this problem is seen.
>>> That would also be an option.
>> Assuming there is a way to turn off READDIRPLUS on the
>> server side... I'll look into it... Or are you suggesting
>> that we have a mount option to turn off READDIRPLUS on the
>> client side? (Note: I believe other implementations have
>> this mount option if that means anything)....
>Not too surprising, there does not seem to be away to
>disable READDIRPLUS on the server side.... so...
>Since it was incredibly easy to disable READDIRPLUS
>from the client side... I went ahead came up and tested
>the attached patches...
>
>Again, I believe there are other implementations, like Apple,
>that have this type of knob so in the end, this might be
>a good thing to have in general... It definitely helps with
>broken Tru64 servers... So please consider...
>
>tia,
>
>steved.
>
>Added support to turn off the NFSv3 READDIRPLUS RPC.
>
>Signed-off-by: Steve Dickson <[email protected]>
>
>----------------------------------------------
>--- linux-2.6.20.i686/fs/nfs/super.c.orig 2007-03-05 11:26:41.130885000 -0500
>+++ linux-2.6.20.i686/fs/nfs/super.c 2007-03-06 16:10:13.390550000 -0500
>@@ -291,6 +291,7 @@
> { NFS_MOUNT_NOAC, ",noac", "" },
> { NFS_MOUNT_NONLM, ",nolock", "" },
> { NFS_MOUNT_NOACL, ",noacl", "" },
>+ { NFS_MOUNT_NORDIRPLUS, ",nordirplus", "" },
> { 0, NULL, NULL }
> };
> const struct proc_nfs_info *nfs_infop;
>--- linux-2.6.20.i686/fs/nfs/client.c.orig 2007-03-05 11:26:40.995885000 -0500
>+++ linux-2.6.20.i686/fs/nfs/client.c 2007-03-06 11:07:23.208538000 -0500
>@@ -618,7 +618,8 @@
> if (clp->cl_nfsversion == 3) {
> if (server->namelen == 0 || server->namelen > NFS3_MAXNAMLEN)
> server->namelen = NFS3_MAXNAMLEN;
>- server->caps |= NFS_CAP_READDIRPLUS;
>+ if (!(data->flags & NFS_MOUNT_NORDIRPLUS))
>+ server->caps |= NFS_CAP_READDIRPLUS;
> } else {
> if (server->namelen == 0 || server->namelen > NFS2_MAXNAMLEN)
> server->namelen = NFS2_MAXNAMLEN;
>--- linux-2.6.20.i686/include/linux/nfs_mount.h.orig 2007-02-04
>13:44:54.000000000 -0500
>+++ linux-2.6.20.i686/include/linux/nfs_mount.h 2007-03-06
>10:59:06.457362000 -0500
>@@ -61,6 +61,7 @@
> #define NFS_MOUNT_NOACL 0x0800 /* 4 */
> #define NFS_MOUNT_STRICTLOCK 0x1000 /* reserved for NFSv4 */
> #define NFS_MOUNT_SECFLAVOUR 0x2000 /* 5 */
>+#define NFS_MOUNT_NORDIRPLUS 0x4000 /* 5 */
> #define NFS_MOUNT_FLAGMASK 0xFFFF
>
> #endif
>
>Adds the -o nordirplus mount option that will disable
>NFS clients from using the READDIRPLUS RPC.
>
>Signed-off-by: Steve Dickson <[email protected]>
>
>------------------------------
>--- nfs-utils-1.0.12/utils/mount/nfs_mount.h.orig 2007-03-06
>15:41:19.557090000 -0500
>+++ nfs-utils-1.0.12/utils/mount/nfs_mount.h 2007-03-06
>15:44:22.888922000 -0500
>@@ -63,6 +63,7 @@
> #define NFS_MOUNT_BROKEN_SUID 0x0400 /* 4 */
> #define NFS_MOUNT_NOACL 0x0800 /* 4 */
> #define NFS_MOUNT_SECFLAVOUR 0x2000 /* 5 */
>+#define NFS_MOUNT_NORDIRPLUS 0x4000 /* 5 */
>
> /* security pseudoflavors */
>
>--- nfs-utils-1.0.12/utils/mount/nfsmount.c.orig 2007-03-06
>15:41:19.582094000 -0500
>+++ nfs-utils-1.0.12/utils/mount/nfsmount.c 2007-03-06 15:44:53.509748000 -0500
>@@ -788,6 +788,10 @@
> data->flags &= ~NFS_MOUNT_NOACL;
> if (!val)
> data->flags |= NFS_MOUNT_NOACL;
>+ } else if (!strcmp(opt, "rdirplus")) {
>+ data->flags &= ~NFS_MOUNT_NORDIRPLUS;
>+ if (!val)
>+ data->flags |= NFS_MOUNT_NORDIRPLUS;
> #endif
> } else {
> bad_option:
>@@ -975,6 +979,7 @@
> #endif
> #if NFS_MOUNT_VERSION >= 5
> printf("sec = %u ", data.pseudoflavor);
>+ printf("readdirplus = %d ", (data.flags & NFS_MOUNT_NORDIRPLUS) != 0);
> #endif
> printf("\n");
> #endif
>--- nfs-utils-1.0.12/utils/mount/nfs.man.orig 2007-03-06
>15:41:19.431090000 -0500
>+++ nfs-utils-1.0.12/utils/mount/nfs.man 2007-03-06 16:06:29.487656000 -0500
>@@ -272,6 +272,11 @@
> .I udp
> Mount the NFS filesystem using the UDP protocol. This
> is the default.
>+.TP 1.5i
>+.I nordirplus
>+Disables NFSv3 READDIRPLUS RPCs. Use this options when
>+mounting servers that don't support or have broken
>+READDIRPLUS implementations.
> .P
> All of the non-value options have corresponding nooption forms.
> For example, nointr means don't allow file operations to be
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>NFS maillist - [email protected]
>https://lists.sourceforge.net/lists/listinfo/nfs
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Talpey, Thomas wrote:
> The current code already supports disabling READDIRPLUS to
> servers that don't support it. It happens after the first bad
> response. The intentional option is a good idea for other
> reasons though, huge directories yield huge attributes.
Yes... I agree this could be useful in other applications...
>
> One problem I see with the mount option is that it might be
> silently ignored by old mount binaries. That will confuse users
> who install a new kernel and don't update util-linux/nfs-utils.
The problem is not so much old mount binaries, since they will fail
with something similar to "Unsupported nfs mount option: nordirplus",
its using new mount binaries with old kernels. The kernels
will silently ignore the option. One could tell the option is
not set by catting /proc/mounts (since the "nordirplus" would
not exist), but I agree there is potential for confusion...
But on he other hand I didn't want to increase the mount
version from 5 to 6 since I think that whole mounting version
stuff is just rats nest.. and Two, I really didn't mounts
to start failing (due to mis-versioning) for a option that
will probably never be used... But it is trivial to increase
the version, but it just causes so many headaches I was
trying to avoid it... Right or wrong that was the reasoning...
steved.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
CgpQZXRlciDDhXN0cmFuZCB3cm90ZToKPiBPbiBUdWUsIDYgTWFyIDIwMDcsIFN0ZXZlIERpY2tz
b24gd3JvdGU6Cj4gCj4+ICsgICAgICAgICAgICAgICB7IE5GU19NT1VOVF9OT1JESVJQTFVTLCAi
LG5vcmRpcnBsdXMiLCAiIiB9LAo+IAo+IEkgcHJlZmVyIHRoZSBvcHRpb24gbmFtZSAibm9yZWFk
ZGlycGx1cyIuIEl0J3Mgb25seSAzIGNoYXJzIGxvbmdlciwgYnV0IAo+IHRoYXQncyBhIHNtYWxs
IHByaWNlIHRvIHBheSBmb3IgYXZvaWRpbmcgY29uZnVzaW9uIGV0Yy4KVGhlIHJlYXNvbiBJIHVz
ZWQgJ25vcmRpcnBsdXMnIHdhcyBiZWNhdXNlIEFwcGxlIHVzZXMgdGhvc2UgY2hhcmFjdGVycwph
bmQgSSB0aG91Z2h0IGl0IGJlIGEgZ29vZCBJIGRpZCB0byB0cnkgYW5kIGtlZXAgdGhpbmdzIGNv
bnNpc3RlbnQuCkJ1dCBpbiB0aGUgZW5kLCBJIGNvdWxkIGNhcmVsZXNzIHdoYXQgd2UgY2FsbCB0
aGUgb3B0aW9uIGFzIGxvbmcKYXMgdGhlIGZ1bmN0aW9uYWxpdHkgaXMgdGhlcmUuLi4KCnN0ZXZl
ZC4KCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0KVGFrZSBTdXJ2ZXlzLiBFYXJuIENhc2guIEluZmx1ZW5jZSB0
aGUgRnV0dXJlIG9mIElUCkpvaW4gU291cmNlRm9yZ2UubmV0J3MgVGVjaHNheSBwYW5lbCBhbmQg
eW91J2xsIGdldCB0aGUgY2hhbmNlIHRvIHNoYXJlIHlvdXIKb3BpbmlvbnMgb24gSVQgJiBidXNp
bmVzcyB0b3BpY3MgdGhyb3VnaCBicmllZiBzdXJ2ZXlzLWFuZCBlYXJuIGNhc2gKaHR0cDovL3d3
dy50ZWNoc2F5LmNvbS9kZWZhdWx0LnBocD9wYWdlPWpvaW4ucGhwJnA9c291cmNlZm9yZ2UmQ0lE
PURFVkRFVgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpO
RlMgbWFpbGxpc3QgIC0gIE5GU0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKaHR0cHM6Ly9saXN0cy5z
b3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vbmZzCg==
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Chuck Lever wrote:
> A comment...
>
> You've implemented a "negative" -- the usual convention is to
> implement the "positive" option. This is how Apple/*BSD do it for
> READDIRPLUS, and it might be good to follow existing precedent.
>
> I think you should implement "rddirplus" and make it the default.
> That way you get "norddirplus" automatically.
>
> You should also include appropriate man page changes in your patch. ;-D
>
If "rddirplus" is the option and is the default, how do you turn it off?
Actually, I am also curious why any existing precedent is interesting.
In general, none of the existing precedents have been followed in the
past... :-)
Thanx...
ps
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Chuck Lever wrote:
> You've implemented a "negative" -- the usual convention is to implement
> the "positive" option. This is how Apple/*BSD do it for READDIRPLUS,
> and it might be good to follow existing precedent.
True... but I pattern it after the our 'noacl' option....
so I am following the existing precedent (using the same characters as
Apple) but only to a point... ;-) How much precedent can one take! :-D
>
> I think you should implement "rddirplus" and make it the default. That
> way you get "norddirplus" automatically.
Take a closer look... -o rdirplus is the default... and -o nordirplus
is not...
>
> You should also include appropriate man page changes in your patch. ;-D
Maybe the man page can be worded better...
steved.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs