Danke für den Tipp mit "strace -v".
Mein Testcase sieht jetzt so aus:
Code:
# ls -la
drwxr-xr-x 6 openvpn root 8192 Jun 12 14:14 .
drwxr-xr-x 1 ftpuser users 2048 Jan 1 2000 ..
drwxr-xr-x 2 root root 4096 Jun 12 14:13 dir-a
drwxr-xr-x 2 root root 4096 Jun 12 14:13 dir-b
drwxr-xr-x 2 root root 4096 Jun 12 14:13 dir-c
-rw-r--r-- 1 root root 36 Jun 12 14:14 file-a
-rw-r--r-- 1 root root 43 Jun 12 14:14 file-b
-rw-r--r-- 1 root root 50 Jun 12 14:14 file-c
drwx------ 2 root root 16384 Jun 10 20:12 lost+found
Ich habe noch einmal "ls" ausgeführt mit strace. Hier die Spuren:
Funktionierendes erstes "ls":
Code:
15947 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
15947 fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
15947 getdents64(3, {{d_ino=2, d_off=1, d_type=DT_DIR, d_reclen=24, d_name="."} {d_ino=2, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} {d_ino=11, d_off=3, d_type=DT_DIR, d_reclen=32, d_name="lost+found"} {d_ino=23089, d_off=4, d_type=DT_DIR, d_reclen=32, d_name="dir-a"} {d_ino=15393, d_off=5, d_type=DT_DIR, d_reclen=32, d_name="dir-b"} {d_ino=30785, d_off=6, d_type=DT_DIR, d_reclen=32, d_name="dir-c"} {d_ino=12, d_off=7, d_type=DT_REG, d_reclen=32, d_name="file-a"} {d_ino=13, d_off=8, d_type=DT_REG, d_reclen=32, d_name="file-b"} {d_ino=14, d_off=9, d_type=DT_REG, d_reclen=32, d_name="file-c"}}, 32768) = 272
15947 getdents64(3, {}, 32768) = 0
15947 close(3) = 0
15947 fstat64(1, {st_dev=makedev(0, 11), st_ino=5, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=1000, st_gid=5, st_blksize=1024, st_blocks=0, st_rdev=makedev(136, 2), st_atime=2011/06/12-14:15:37, st_mtime=2011/06/12-14:15:37, st_ctime=2011/06/12-13:56:23}) = 0
15947 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7756000
15947 write(1, "dir-a dir-b dir-c file-a file-b file-c lost+found\n", 56) = 56
15947 close(1) = 0
15947 munmap(0xb7756000, 4096) = 0
15947 close(2) = 0
15947 exit_group(0) = ?
Karp0tes zweites "ls":
Code:
15957 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
15957 fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
15957 getdents64(3, {{d_ino=2, d_off=1, d_type=DT_DIR, d_reclen=24, d_name="."} {d_ino=2, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} {d_ino=0, d_off=3, d_type=DT_UNKNOWN, d_reclen=32, d_name="lost+found"} {d_ino=0, d_off=4, d_type=DT_UNKNOWN, d_reclen=32, d_name="dir-a"} {d_ino=0, d_off=5, d_type=DT_UNKNOWN, d_reclen=32, d_name="dir-b"} {d_ino=0, d_off=6, d_type=DT_UNKNOWN, d_reclen=32, d_name="dir-c"} {d_ino=0, d_off=7, d_type=DT_UNKNOWN, d_reclen=32, d_name="file-a"} {d_ino=0, d_off=8, d_type=DT_UNKNOWN, d_reclen=32, d_name="file-b"} {d_ino=0, d_off=9, d_type=DT_UNKNOWN, d_reclen=32, d_name="file-c"}}, 32768) = 272
15957 getdents64(3, {}, 32768) = 0
15957 close(3) = 0
15957 close(1) = 0
15957 close(2) = 0
15957 exit_group(0) = ?
Wie man sieht ist beim zweiten "ls" die Inode- und Datei-Typ-Information falsch: d_ino=0 und d_type=DT_UNKNOWN für alle Einträge des NFS-Mounts ausser für . und ..
Darauf hin habe ich mit tcpdump mit geschnitten, was beim "ls" auf das Verzeichnis passiert(siehe Anhang). Das Ergebnis ist frustierend, da beim zweiten "ls" keine NFS-Pakete zwischen Client und Server (7390) versendet werden. Das sieht IMO nach einem komischen Clientproblem aus oder AVM hat in den 2.6.19.2 Sourcen irgendwas verändert, was das Verhalten des NFS-Servers in unbekannter Weise verändert und den Client irritiert.
Als nächstes würde ich mir mal einen Diff der Kernelsourcen von 2.6.19 zwischen einer Box mit funktionierendem Kernel-Space-nfsd und der 7390 anschauen wollen. 7[25]70 vs 7390. Ich bin für weitere Vorschläge jedoch offen.
Zitieren
Zitat von abraXxl
