I upgraded from 2.4.28 to 2.6.10 (and then .11) a month ago. In 2.6.11
at least, and probably in 2.6.10 (alas, I didn't notice this behaviour
early enough to be sure: I can reboot into 2.6.10 and see if it
disappears if anyone wants), the Linux NFS client / kernel server
combination has been absolutely *flooding* the network with ACCESS
requests (and to a somewhat lesser extent GETATTR).
This is far worse than anything I've seen in 2.4: even on a 100Mb/s net,
it slows (e.g.) configure runs down to a tenth or less of their normal
speed. A packet dump of ten seconds worth of a run of bfd configure
shows more than 40,000 UDP packets, 95% of them GETATTR and ACCESS
requests for the same inodes repeated over and over again microseconds
apart. There appears to be no caching of ACCESS results being done
whatsoever.
(Packet dumps from this ten-second slice of configure run are available,
but they're >8Mb, so I'm not attaching them here.)
The filesystem I tested this on (and where I see most of the problems,
but it's the most heavily used of my NFS filesystems, so this is
unsurprising) is exported from a 2.6.11.6 SPARC64 box as
`rw,no_root_squash,async,wdelay,no_subtree_check' (from
/proc/fs/nfs/exports), and imported onto a number of 2.6.11.6 i386-class
boxes (Pentium, Athlon IV...) all of which show the same symptoms.
I'm running nfs-utils 1.0.7 across the board, but this doesn't seem to
be the class of problems I've seen before where mount fails to
communicate the NFS options properly to the kernel and leaves out the
async or something like that. (I think this has to be a client bug
or obscure feature or something.)
I speculate that this line from the NFS FAQ is relevant:
> The Linux NFS client should cache the results of these ACCESS
> operations. In fact, in the new 2.6.x kernels, it does this and it
> extends ACCESS checking to all users to allow for generic uid/gid
> mapping on the server.
If this means `massive numbers of ACCESS requests will happen when using
2.6', then, well, I'm not using UID/GID mapping[1] and I don't need ACLs
if they do *this* to performance: how do I turn this behaviour off?
[1] in fact, until I read this FAQ entry I was unaware it existed: I
mourned its loss when I moved away from unfsd / ugidd, so if
it's back, excellent!
--
This is like system("/usr/funky/bin/perl -e 'exec sleep 1'");
--- Peter da Silva
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
to den 21.04.2005 Klokka 18:31 (+0100) skreiv Nix:
> I upgraded from 2.4.28 to 2.6.10 (and then .11) a month ago. In 2.6.11
> at least, and probably in 2.6.10 (alas, I didn't notice this behaviour
> early enough to be sure: I can reboot into 2.6.10 and see if it
> disappears if anyone wants), the Linux NFS client / kernel server
> combination has been absolutely *flooding* the network with ACCESS
> requests (and to a somewhat lesser extent GETATTR).
The following patch has already been applied to the 2.6.12-rc series.
http://client.linux-nfs.org/Linux-2.6.x/2.6.12-rc1/linux-2.6.12-00-fix_access.dif
Cheers,
Trond
--
Trond Myklebust <[email protected]>
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs