On Fri, 20 Nov 2009, Alec T. Habig wrote: > Hi folks, > > When users are running nautilus on a machine where their directories are > nfs-mounted, nautilus spends a substantial fraction of the client > machine's CPU, ~1.5Mbps of bandwidth, and a large load on the server's > nfsd I/O wait states. It looks like it is constantly stat'ing all the > files it can, although I haven't confirmed that with strace. > > Initially the problem was with the gamin daemon doing the same thing, > but one can ask it not to do so by adding > > fsset nfs none > > to /etc/gamin/gaminrc > > and it behaves. The problem then moves to nautilus itself, which acts > as if it's not satisfied with the gamin's lack of up-to-the-second > response and tries to do it itself. > > Anyone know of a way to configure nautilus to behave? The alternative > is to annoy my users by making them all switch to kde instead, but > that's better than letting gnome DOS my nfs server. > > thanks, > Alec > > PS - SL5.4, although it also happened (with less dire consequences) in > SL5.3. I've not yet tested things properly on sl54 but for sl53 we tweaked the gamin config to tell it to poll the nfs servers less agressivly, and to hack a couple of other paths which gamin was being confused about (somehow it was convinced that they supported inotify but they don't)... $ cat /etc/gamin/gaminrc # $Id: gaminrc,v 1.2 2009/01/22 00:37:56 jp107 Exp $ # # Teach gamin to poll these paths since in DAMTP they are symlinks to # NFS but it thinks they can be checked with inotify - and they can't! poll /var/spool/mail/* /var/mail/* 30 # # This should be enough to set the poll interval for 'nfs' type # file-systems - otherwise it defaults to polling every 10 seconds... #fsset nfs poll 30 fsset nfs poll 20 in sl53 nautilus was only causing gamin to poll a few bits of the home directory (e.g. ~/Desktop/) every 10 seconds so it wasn't a really _big_ problem. I'm guessing that if gamin is told it can't monitor NFS then nautilus may do some polling itself... -- Jon