On 07/26/12 16:25, Allen Chen wrote:
On 07/26/2012 03:19 PM, m.roth@xxxxxxxxx wrote:
Allen Chen wrote:
On 07/11/2012 10:38 AM, m.roth@xxxxxxxxx wrote:
From: Corey Kovacs<corey.kovacs@xxxxxxxxx>
<snip>
On Tue, Jul 10, 2012 at 8:47 PM, mark<m.roth@xxxxxxxxx> 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.
# cat /etc/exports
/images 192.168.1.0/24(rw) 10.235.4.2/32(rw)
Since you're not specifying explicitly, I suspect it's doing async.
mark
--
Why the Libertarian idea of a privatized courts won't work,
from a slogan from Kenya: why bother hiring a lawyer, when
you can buy a judge?
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
