lkml.org 
[lkml]   [2001]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectProblems with NFS between IRIX Server and Linux client
Date
From
OK.  Strange problem here with NFS that has been experienced on both
Debian machines and Red Hat machines. I believe the problem ties in
to NFS support in the Linux kernel, but I could be entirely wrong.

Scenario: Serving a filesystem from IRIX 6.5 host. Accessing it with
a Linux 2.4.9 Debian Woody machine. Directory content listings and
directory info are not consistently reported to the client.

Symptoms: For directories with #files approx > 200, filename
completion in bash does not work, many applications do not show files
in the directory.

I cannot pinpoint the number of files that throws it off. In a test
directory, I've created a number of files by looping through a bash
script:

for i in $(seq 1 200) ; do touch $i ; done

With 200 files, I was able to type 'ls 1<tab>' and get the familiar:

"Display all 111 possibilities? (y or n)"

When I up'd the sequence to 210 it worked, 220, it did not. From 220
files, I started to delete one file at a time until filename
completion started to work. By 180, I could still not get a filename
completion. I increased the number of files I removed by blocks of
ten. At 159 files in the directory, I got that familiar list of files
that would complete 'ls 1<tab>'. I would have expected the filename
completion to start working again at 200 files, but this is what
is happening.

nfsstat(1) of the nfs-common package reports no calls to nfs v2.
The client stats are as follows:

Client rpc stats:
calls retrans authrefrsh
251193 2 0

Client nfs v3:
null getattr setattr lookup access readlink
0 0% 339 0% 4941 1% 192725 77% 719 0% 13 0%
read write create mkdir symlink mknod
10893 4% 16079 6% 3119 1% 2 0% 3 0% 0 0%
remove rmdir rename link readdir readdirplus
2715 1% 1 0% 2425 0% 223 0% 1632 0% 0 0%
fsstat fsinfo pathconf commit
11 0% 11 0% 0 0% 13222 5%

The IRIX Server reported the following:

Server RPC:
calls badcalls nullrecv badlen xdrcall duphits
dupage
88596597 0 7661399 0 0 2186
557.33

Server NFS V3:
calls badcalls
51031056 0
null getattr setattr lookup access readlink
52998 0% 1394893 2% 827158 1% 19540449 38% 1294352 2% 50714 0%
read write create mkdir symlink mknod
6306234 12% 7379734 14% 504682 0% 8581 0% 4185 0% 1 0%
remove rmdir rename link readdir readdir+
458294 0% 5198 0% 132737 0% 33172 0% 390736 0% 105473 0%
fsstat fsinfo pathconf commit
5377509 10% 4612155 9% 12342 0% 2539452 4%

An strace of scan(1) from nmh to two different directories shows the
contrasting ipc calls:

Calling "scan +inbox":

brk(0x809c000) = 0x809c000
stat64(0x8097690, 0xbfffd21c) = 0
access("/home/chad/Mail/inbox", W_OK) = 0
SYS_199(0x401940b8, 0x2, 0x40194e00, 0x40191ed0, 0x8098118) = 713
ipc_subcall(0x3, 0x80987c8, 0x2000, 0x2) = 2672
ipc_subcall(0x3, 0x80987c8, 0x2000, 0x2) = 0
close(3) = 0
open("/home/chad/Mail/inbox/.mh_sequences", O_RDONLY) = 3
.
.
.

Calling "scan +ima/cron/2001-10":

brk(0x809c000) = 0x809c000
stat64(0x8097698, 0xbfffd20c) = 0
access("/home/chad/Mail/ima/cron/2001-10", W_OK) = 0
SYS_199(0x401940b8, 0x2, 0x40194e00, 0x40191ed0, 0x8098118) = 713
ipc_subcall(0x3, 0x80987c8, 0x2000, 0x2) = 8184
close(3) = 0
writev(2, [{"scan", 4}, {": ", 2}, {"no messages in ima/cron/2001-10",
31}, {"\n", 1}], 4scan: no messages in ima/cron/2001-10
) = 38
_exit(1) = ?

I know this isn't a whole lot to go on, but if I could get a direction
to start looking, I would really appreciate it.

--
Chad Walstrom <chewie@wookimus.net> | a.k.a. ^chewie
http://www.wookimus.net/ | s.k.a. gunnarr
Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:08    [W:0.058 / U:7.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site