> "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).
> >
> > Neither the client, nor the server appear to run out of memory.
> > There are no entries in the logs of either machines to show the
> > problem.
> >
> > This is 100% repeatable.
>
> I have previously reported a similar problem,
> reproduceable with a single machine:
>
> mount localhost:/ /x
> dd if=/dev/zero of=/junk bs=1024k count=200
> diff junk /x/junk
>
> This often (not always) fails with *differences* on the "diff".
> Happens with userland NFS only; not (yet) with knfsd.
>
> The system is a P2-450Mhz with 128MB and *very fast*
> raid0 (18-20MByte/sec) disk I/O.
> --
> mlord@pobox.com
>
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...
The mounted file-system becomes inaccessible. It can be `umounted`,
then `mounted` and it becomes accessible again. The return message
from `cp` is I/O error. `strace /bin/ls /mnt` returns:
[Non pertainent stuff snipped]
lstat("/mnt", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
brk(0x11000) = 0x11000
stat("/mnt", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
open("/mnt", O_RDONLY) = 4
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
brk(0x12000) = 0x12000
readdir(4, {d_ino=135169, d_name="."}) = 1
readdir(4, {d_ino=2, d_name=".."}) = 1
readdir(4, 0x11000) = 0
close(4) = 0
_exit(0) = ?
In other words, its perfectly happy and thinks nothing is mounted.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.1 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Wisdom : It's not a Y2K problem. It's a Y2Day problem.
-
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/