All of lore.kernel.org
 help / color / mirror / Atom feed
From: Judith Flo Gaya <jflo@imppc.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: problem with nfs latency during high IO
Date: Tue, 15 Mar 2011 22:58:00 +0100	[thread overview]
Message-ID: <4D7FE0E8.5050701@imppc.org> (raw)
In-Reply-To: <9CC4990D-6969-4788-8B52-BA5AF2743DE3@oracle.com>



On 3/15/11 10:28 PM, Chuck Lever wrote:
>>>>>> Can you help me on this? I'm I wrong in my supposition (is the patch really applied)? is it possible that my problem is somewhere else?
>>>>> This sounds like typical behavior.
>>>> But it is not like this when I use a RHEL6 as a client to those servers, in this case, the ls only last for some seconds, nothing like the minutes that it takes from my fedora.
>>> Which Fedora systems, exactly?  The fix I described below is almost certainly in RHEL 6.
>> Fedora Core 14, 64 bit, 2.6.35.6-45
> Right, you mentioned that in your OP.  Sorry.
no problem
>>>>> POSIX requires that the mtime and file size returned by stat(2) ('ls -l') reflect the most recent write(2).  On NFS, the server sets both of these fields.  If a client is caching dirty data, and an application does a stat(2), the client is forced to flush the dirty data so that the server can update mtime and file size appropriately.  The client then does a GETATTR, and returns those values to the requesting application.
>>>>>
>>>> ok, sorry, I know this is a very stupid question but. what do you mean by dirty data?
>>> Dirty data is data that your application has written to the file but which hasn't been flushed to the server's disk.  This data resides in the client's page cache, on its way to the server.
>> ok, understood. Then the sysctl change that you suggest, I've been checking both distributions, RHEL6 and FC14 and they share the same value... I assume by this that changing this value will not "help", am I right?
> It should improve behavior somewhat in both cases, but the delay won't go away entirely.  This was a workaround we gave EL5 customers before this bug was addressed.  In the Fedora case I wouldn't expect a strongly deterministic improvement, but the average wait for "ls -l" should go down somewhat.
I saw that the value was 20, I don't know the impact of changing the 
number by units or tens... Should I test with 10 or this is too much? I 
assume that the behavior will change immediately right?
j

  reply	other threads:[~2011-03-15 21:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-12 12:58 problem with nfs latency during high IO Judith Flo Gaya
2011-03-15 16:24 ` Chuck Lever
2011-03-15 17:25   ` Judith Flo Gaya
2011-03-15 18:03     ` Chuck Lever
2011-03-15 18:15       ` Chuck Lever
2011-03-17  1:21         ` Harshula Jayasuriya
2011-03-15 21:33       ` Judith Flo Gaya
2011-03-15 21:28         ` Chuck Lever
2011-03-15 21:58           ` Judith Flo Gaya [this message]
2011-03-15 22:10             ` Chuck Lever
2011-03-16 11:45               ` Judith Flo Gaya
2011-03-16 13:24                 ` Chuck Lever
2011-03-16 13:42                   ` peter.staubach
2011-03-16 15:18                   ` Jim Rees
2011-03-16 15:31                     ` Jim Rees
2011-03-16 16:52                       ` Judith Flo Gaya
2011-03-16 23:51                 ` Simon Kirby
  -- strict thread matches above, loose matches on Subject: below --
2011-03-15 16:25 Judith Flo Gaya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D7FE0E8.5050701@imppc.org \
    --to=jflo@imppc.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.