[Beowulf] quick note on Redhat NFS issues with NAS units
Joe Landman
landman at scalableinformatics.com
Sun Dec 26 12:59:18 PST 2004
Folks:
Been looking into why a Redhat EL3 WS x86_64 client hangs when
accessing a NAS based upon SuSE 9x. Turns out there are two problems.
I can reliably cause the problem to appear/dissappear on my test
hardware, and I thought others on this group would like to see what I
did to make the problems dissappear.
Problem manifests itself with RedHat EL3 WS x86_64 clients. I have
not been able to replicate it with non-RHEL3 based clients, on the same
hardware, including FC2/FC3/Ubuntu/SuSE9x/... Problem does not show up
in 32 bit mode from what I can tell (need more testing but preliminary
data seems to support this). Motherboard are Tyan s288x units. All
have the Broadcom chipset ethernets.
By default RedHat installs tg3 kernel modules to drive these chips. I
have not been able to make the problem go away using the tg3 driver. So
I replaced the tg3 driver with the bcm570x driver from Broadcom's
download site. This did not make the problem go away, though NFS mount
now respected the intr option (did not with the tg3).
Next, I changed from udp to tcp. The original fstab line was
192.168.2.17:/big /big nfs udp,intr,bg 0 0
and the new one is
192.168.2.17:/big /big nfs
tcp,intr,bg,wsize=32768,rsize=32768 0 0
MTU changes did not affect the results (though they did improve on some
of the test timing).
Without both of these changes, the RedHat client hangs with a simple ls
(btw: strace is your friend)
[root at hammer root]# strace ls /big
execve("/bin/ls", ["ls", "/big"], [/* 28 vars */]) = 0
uname({sys="Linux", node="hammer.scalableinformatics.com", ...}) = 0
brk(0) = 0x513000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2a9566c000
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
...
stat("/big", {st_mode=S_IFDIR|0777, st_size=8192, ...}) = 0
open("/big", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0777, st_size=8192, ...}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, <unfinished ...>
With the changes, it ls'es quite nicely with no hangs. I can reliably
and repeatably get the hang condition by switching back to udp (and the
other mount line). I can reliably and repeatedly get the hang condition
by switching back to the tg3 driver.
This occurred with the Rocks toolkit (based upon RHEL3 WS). The
workaround involves using our finishing scripts.
I figured I would share the solution, as I spent a bit of time tracking
it down and trying to reproduce it and solve it.
Joe
ps: if there are some Redhat people reading the list, you know, we would
like some modern kernels, and not lots of backported stuff, not to
mention xfs, and other goodies ... (yeah, I know, wait till EL4, ...)
--
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics LLC,
email: landman at scalableinformatics.com
web : http://www.scalableinformatics.com
phone: +1 734 612 4615
More information about the Beowulf
mailing list