Re: NFS client screwy directories.

[Brian May <bam@debian.org>]

>>>>> "Douglas" == Douglas Eck <doug@idsia.ch> writes:

    Douglas> I am running debian sid. I am on a network with my
    Douglas> homedirectory served via NFS by a Dell intel box (note,
    Douglas> not IRIX) running Redhat 7.1.

    Douglas> Under kernels 2.4.14 [patched with sourceforge NFS patch
    Douglas> linux-2.4.14-seekdir.dif] and also with unpatched 2.4.7 I
    Douglas> have problems with screwed up file reading and writing
    Douglas> under nfs. Here's what happens:

What is that patch?

    Douglas> If I create a large number of files very quickly... for
    Douglas> example by untarring an archive or running a fast script
    Douglas> over a directory mounted via NFS, the ls command cannot
    Douglas> find the files recently written to:

I was really tearing my hair out over another problem today, maybe it
is related, maybe not.

I mounted a (mostly stable) root partition, over NFS as /mnt. I then
"chroot /mnt" into it, and try to install the libc6, using dpkg (no
apt):

dpkg -i /var/cache/apt/archives/libc6_2.1.3-19_i386.deb

There are two errors I always get, for no good reason.

rmdir("/lib/libthread_db-1.0.so.dpkg-new") = -1 ENOENT (No such file or directory)
rmdir("/lib/libthread_db-1.0.so.dpkg-tmp") = -1 ENOENT (No such file or directory)
open("/lib/libthread_db-1.0.so.dpkg-new", O_WRONLY|O_CREAT|O_EXCL, 0444) = 7
shmat(7, 0, 0x3ptrace: umoven: Input/output error
)                        = ?
fstat64(0x7, 0xbfffeecc)                = 0

this one really has me puzzled. Restarting the NFS-server usually helps.


scrooge:stable:/# dpkg -i /var/cache/apt/archives/libc6_2.1.3-19_i386.deb 
(Reading database ... 62657 files and directories currently installed.)
Preparing to replace libc6 2.1.3-18 (using .../libc6_2.1.3-19_i386.deb) ...
Unpacking replacement libc6 ...
dpkg: error processing /var/cache/apt/archives/libc6_2.1.3-19_i386.deb (--install):
 unable to create `./lib/libnss_compat-2.1.3.so': Too many levels of symbolic links
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/libc6_2.1.3-19_i386.deb

this is more typically. Too many symbolic links?????? I can't see
any symbolic links here: 

scrooge:stable:/# ls -l ./lib/libnss_compat*
-rw-r--r--    1 root     root        41356 Mar 26  2001 ./lib/libnss_compat-2.1.3.so
-rw-r--r--    1 root     root        41660 Oct 31 09:44 ./lib/libnss_compat-2.2.4.so
lrwxrwxrwx    1 root     root           22 Nov 16 12:04 ./lib/libnss_compat.so.2 -> libnss_compat-2.2.4.so

(obviously, yes, I have been screwing around with my system a bit,
with the different versions of glibc... but I don't think that is a
factor with this, the errors always seem to come from the kernel, as
shown with strace.)

strace showed the error occurring when trying to create the .dpkg-new
file, IIRC. Unfortunately I can't get it to reproduce this error
again, right now :-(.

Another strace shows:

rename("//lib/libBrokenLocale-2.1.3.so.dpkg-tmp", "//lib/libBrokenLocale-2.1.3.so") = 0
rmdir("//lib/libBrokenLocale-2.1.3.so.dpkg-new") = -1 ENOENT (No such file or directory)
lstat64(0x82f7fe8, 0xbffff91c)          = 0
rename("//lib/ld-2.1.3.so.dpkg-tmp", "//lib/ld-2.1.3.so") = 0
rmdir("//lib/ld-2.1.3.so.dpkg-new")     = -1 ENOENT (No such file or directory)
close(6dpkg-deb: subprocess paste killed by signal (Broken pipe)
)                                = 0

haven't seen that one until now.

Any ideas?
-- 
Brian May <bam@debian.org>