FWIW I experienced this with a RH-5.2 (+ updates) & kernel 2.2.{1,2-pre2}
(SMP,monolithic,all-SCSI,3c905,IP-aliasing) client to SunSITE UK which I
guess isn't running Linux nfsd ;)
> Good. I have also confirmed that it's not a problem with multiple
> files. One large file (210 megabytes), when copied from a remotely-
> mounted file-system to /tmp will fail, however, copying it to /dev/null
> will not!???? Now, the null-sink doesn't have to do locking. Copying
> to a file-system does --erm...
Quite. I tried to copy an 18MB file to /tmp, and NFS stuck at around 17:
bad news when your homes are over NFS!
> The mounted file-system becomes inaccessible. It can be `umounted`,
> then `mounted` and it becomes accessible again. The return message
[snip]
Hmm.. I couldn't umount; maybe I hadn't used "-o intr" then. However,
I resorted to samba-mounting SunSITE instead, which just about worked,
until my NFS "-o hard,intr,nolock" home mounts keeled over again :(
I don't want to return to 2.0; that would mean too many recompiles and
worse SMP. So, if anyone can think of any tests I can run, I should be
able to find the time to do it.
Matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/