Bug 800181: NFSv4 on RHEL 6.2 over six times slower than 5.7

[m.roth at 5-cent.us]

Allen Chen wrote:
> On 07/11/2012 10:38 AM, m.roth at 5-cent.us wrote:
>>> From: Corey Kovacs<corey.kovacs at gmail.com>
<snip>
>>> On Tue, Jul 10, 2012 at 8:47 PM, mark<m.roth at 5-cent.us>  wrote:
>> <snip>
>>>> I'll say it one more time: we found the problem on CentOS. We went to
>>>> our test RHEL system. Updated it. Exported a directory *from* the RHEL
>>>> box to itself, to /mnt/foo, and ran the test, and got the same results.
>>>>
>>>> In fact, I ran it twice today, updating the kernel in between, and
>>>> with 6.3, it's taking a consistent 7.5 min, instead of the 6.5 we were
>>>> getting with 6.2
>>>> <snip>
>>>>
>>>>   Now, all that said and done, here are some questions for you which
>>>> might help us figure what would help.
>>>>> 1. What options are present on the mount? (cat /proc/mounts, thinks
>>>>> like sync can be a problem)
>> /scratch/foo<same_server>(rw,sync,no_wdelay)
>>
<snip>
>>>>   2. What does your /etc/exports config look like on your server node
>>>> (cat /etc/exports)
<snip>
>>>> Do you mean selinux auditing? As I said, doing it on the local drive
>>>> takes seconds. Doing it from a 5.x NFS server takes about 1.5 min.
>> Therefore,
>>>> there's nothing that could affect it on the one server.
>>
> I did a quick test on my CentOS 6.2, and I don't see any slow untar.
> Here are the steps I did:
>
> On server:
> # uname -a
> Linux backup62 2.6.32-220.el6.i686 #1 SMP Tue Dec 6 16:15:40 GMT 2011
> i686 i686 i386 GNU/Linux
>
> on my desktop:
> # uname -a
> Linux centos62 2.6.32-220.el6.i686 #1 SMP Tue Dec 6 16:15:40 GMT 2011
> i686 i686 i386 GNU/Linux
> # mount -t nfs server-ip:/images /mnt
> # time tar xvfz /mnt/hs21.tgz
> ...
> real    0m5.496s
> user    0m0.438s
> sys    0m0.176s
>
> # cd /mnt
> time tar xvfz hs21.tgz
> ...
> real    0m20.634s
> user    0m0.414s
> sys    0m0.135s
>
> # ll hs21.tgz
> -rw-r--r-- 1 root root 43725908 Apr  2  2008 hs21.tgz

Allen,

   what does /etc/exports read? On my system, if I have it as

/scratch/foo <fwdn.hostname>(rw,sync,no_wdelay)

I get the delay. Following someone's post a week or two ago, I tried
/scratch/foo <fwdn.hostname>(rw,async,no_wdelay)

and it goes at a reasonable speed. That (a)sync seems to override
everything else. However, I'm trying to get together with my manager to
decide if we want to use async - that's above my pay grade, and we have to
consider that we have a fair number of users that run jobs that run for
literally days, sometimes over a week, and loss of any data at all might
mean false results, or having to rerun it.
>
> Is there anything you can do with the DNS settings on the server side?

DNS has nothing to do with the test case.

     mark