Re: nfs client performance while server is down

[Peter Staubach <staubach@redhat.com>]

Whoop Whouzer wrote:
> I am not stating this is an NFS problem at all. I am not asking anybody to fix
> anything.
> I asked if this issue was by design. I was told it wasn't (as nfs is stateless).
> So, therefore I considered it as a bug (which I don't believe to
> reside in either nfs or nautilus). I am just trying to figure out
> where the problem lies.
> 

There is a misconception here.  NFS is not stateless.  To
be accurate, the NFSv2 and NFSv3 protocols were defined in
such as to allow the NFS server to be stateless.  The server
was not supposed to be required to remember anything about
what a client was doing from operation to the next.  (In
reality, there are non-idempotent operations, ie. operations
which can not be done twice and get the same results, so it
is very helpful if the server remembers some state.)

NFS clients have always been _very_ stateful.  They have to
know about all mounted file systems, open files, current
directories, etc.

The problem here is some application which is attempting to
touch all of the mounted file systems.  When it tries to
touch one from a non-responsive NFS server, then it hangs.
This represents an architectural problem with the
application making an assumption that is okay and acceptable
to access all file systems which are currently mounted.
This assumption leads to situations such as you are observing.

This isn't new.

		ps

> I am not talking about implementing "disconnected NFS" mode,
> synchronisation or anything like that. There is not something missing,
> there is something not working properly, somewhere, and I'm trying to
> find out where..
> 
> On Wed, Jan 27, 2010 at 8:09 PM, Trond Myklebust
> <trond.myklebust@fys.uio.no> wrote:
>> So? I don't see why that would be an NFS problem.
>>
>> As far as I can see from this thread, you are basically asking us to fix
>> these broken applications by implementing a "disconnected NFS" mode.
>> While that may indeed be a cool thing to support, I haven't seen anybody
>> so far stepping up and saying that they have the time and resources to
>> work on it. Are you volunteering?
>>
>> Trond
>>
>> On Wed, 2010-01-27 at 19:47 +0100, Whoop Whouzer wrote:
>>> ok, but it's not just GNOME/nautilus behaviour. For one, I am
>>> experiencing problems with just about all applications that require
>>> (local) disk access. Furthermore, problems have also been reported
>>> with xfce/thunar and also with KDE.
>>>
>>> A bug for this issue has just been created for xfce/thunar:
>>> http://bugzilla.xfce.org/show_bug.cgi?id=6185
>>>
>>> On Wed, Jan 27, 2010 at 7:40 PM, Trond Myklebust
>>> <trond.myklebust@fys.uio.no> wrote:
>>>> On Wed, 2010-01-27 at 13:23 -0500, Chuck Lever wrote:
>>>>> On 01/26/2010 06:21 PM, J. Bruce Fields wrote:
>>>>>> I wonder if nautilus (or some library it uses) likes to regularly
>>>>>> "statfs" all the filesystems it knows about?
>>>>> The NFS client seems to like to send these periodically, but I've never
>>>>> looked into why.  It's probably triggered by some cache timeout, and
>>>>> gathers recent server file system information.
>>>> No. It is entirely application driven. Furthermore, most of the statfs
>>>> data is uncached, since it should not be performance critical in any
>>>> sane application environment.
>>>>
>>>> IOW: I agree with Bruce that this is most likely GNOME or nautilus
>>>> triggering statfs calls. Indeed, when I do actually open a window on
>>>> some directory it also appears to display the free space.
>>>>
>>>> Trond
>>>>
>>>>
>>>>
>>
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html