Perhaps something in your $PATH is in the NFS mount? Do a network trace and maybe you can see if, in fact, there are actually NFS operations being attempted that you weren't expecting. Then try to figure out why. -Dan > -----Original Message----- > From: Whoop Whouzer [mailto:tiredandnumb@xxxxxxxxx] > Sent: Saturday, January 23, 2010 8:28 AM > To: Peter Chacko > Cc: linux-nfs@xxxxxxxxxxxxxxx > Subject: Re: nfs client performance while server is down > > I don't remember all the different set-ups I tried it on, but I just > confirmed this with the following combinations: > > ubuntu server 10.04 (alpha 2) --> ubuntu desktop 9.10, ubuntu desktop > 10.04 (alpha 2), fedora 12 > ubuntu server 9.10 --> ubuntu desktop 9.10, ubuntu desktop 10.04 > (alpha 2), fedora 12 > > I'll be happy to test it on another client machine (distro) even > another server (although it would require a little more time) > > Here are some examples on the bugreports I noticed and how they do not > seem to get solved: > https://bugzilla.redhat.com/show_bug.cgi?id=175283 > https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/164120 > > regards, > Whoop > > On Sat, Jan 23, 2010 at 4:57 PM, Peter Chacko > <peterchacko35@xxxxxxxxx> wrote: > > Which client OS you observed this behavior ? This has nothing to do > > NFS design, and its purely stateless...Its upto the client OS > > implementation about aspects like how to deal with local > IO, when NFS > > share gets disconnected.. > > > > May be a VFS bug on the local OS you found this problem .. > > > > thanks > > > > On Sat, Jan 23, 2010 at 9:15 PM, Whoop Whouzer > <tiredandnumb@xxxxxxxxx> wrote: > >> Howdy, > >> > >> I was wondering why nfs is designed in such a way that the > performance > >> of an nfs client machine gets very bad when the nfs server > is offline? > >> This is even the case with a soft mount (either via mount > or fstab). > >> Just about every application that requires disk access (not talking > >> about nfs share acces) gets really slow to unresponsive. > For instance > >> nautilus becomes unresponsive when displaying the contents of any > >> folder on the local disk, > >> playing movie files (stored on local disk) let totem or > vlc get stuck > >> on set intervals, even the terminal becomes unresponsive at times. > >> > >> I could understand that these problems would occur while > accessing the > >> nfs share directoiourry while the server is offline, but > why for totally > >> unrelated directories? > >> > >> I have experienced this behaviour on various distro's, and > also found > >> various bug reports on this issue, they don't seem to get solved as > >> this is viewed as nfs design. > >> I see this as a flaw because clients are totally dependent on the > >> server. This would be less of a deal if the entire home directory > >> would be stored on nfs (although I even think some sort of > >> synchronisation technology could and should be implemented in this > >> case). It is a bit odd that (technically) one machine serving some > >> "useless" files to a non-trivial directory on client > machines can take > >> down these client machines. > >> > >> For me the preferred functionality would be: > >> *If an nfs server gets offline the client's nfs share becomes > >> unaccessible, but local directories and applications (that only > >> require local disk access) stay responsive. > >> *If an nfs server gets online (after being offline while the client > >> has not been restarted) the nfs share becomes reconnected. > >> > >> regards, > >> Whoop > >> -- > >> To unsubscribe from this list: send the line "unsubscribe > linux-nfs" in > >> the body of a message to majordomo@xxxxxxxxxxxxxxx > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> > > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-nfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
