Messages in this thread | | | Date | Tue, 23 Feb 1999 11:00:45 +0000 (GMT) | From | Matthew Bernstein <> | Subject | Re: NFS fails after 40 minutes of use |
| |
On Mon, 22 Feb 1999, Richard B. Johnson wrote: > On Mon, 22 Feb 1999, Mark Lord wrote: > > "Richard B. Johnson" wrote: > > > In the following I show that about 40 minutes into an across-the > > > network-backup, the remote mount-point becomes inaccessible. > > > Both machines are running Linux 2.2.1 The server is running a > > > Red Hat 5.2 release. The client is running software accumulated > > > over several years (not a vendor release). [snip]
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/
| |