[root@vcorr1 src]# mount pcgp:/acroot/usr /mnt/
[root@vcorr1 src]# mount -t proc nodev /mnt/proc/
[root@vcorr1 src]# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda1 297560 44188 238004 16% /
/dev/sda5 1683836 1205376 391436 75% /usr
pcgp:/acroot/usr 896851 325365 525150 38% /mnt
[root@vcorr1 src]# mount
/dev/sda1 on / type ext2 (rw)
/proc on /proc type proc (rw,0)
/devpts on /dev/pts type devpts (rw)
/dev/sda5 on /usr type ext2 (rw)
pcgp:/acroot/usr on /mnt type nfs (rw,addr=150.214.224.108)
nodev on /mnt/proc type proc (rw)
[root@vcorr1 src]# ls /mnt/proc/
1 3 333 687 dma ioports misc scsi tty
2 303 334 688 driver kcore modules self uptime
211 317 335 716 execdomains kmsg mounts slabinfo version
233 329 336 bus filesystems ksyms net stat
243 330 337 cmdline fs loadavg partitions swaps
256 331 338 cpuinfo interrupts locks pci sys
269 332 4 devices iomem meminfo ppc_htab sysvipc
[root@vcorr1 src]# du /mnt/
1 /mnt/X11R6/bin
1 /mnt/X11R6/doc
1 /mnt/X11R6/include
1 /mnt/X11R6/lib/X11/app-defaults
[snipped...]
16 /mnt/proc/750
845 /mnt/proc
257420 /mnt
[root@vcorr1 src]# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda1 297560 44189 238003 16% /
/dev/sda5 1683836 1205376 391436 75% /usr
pcgp:/acroot/usr 896851 325365 525150 38% /mnt <---}=
nodev 896851 325365 525150 38% /mnt/proc <---}=
[root@vcorr1 src]# ls /mnt/proc/ <---empty
[root@vcorr1 src]# mount
/dev/sda1 on / type ext2 (rw)
/proc on /proc type proc (rw,0)
/devpts on /dev/pts type devpts (rw)
/dev/sda5 on /usr type ext2 (rw)
pcgp:/acroot/usr on /mnt type nfs (rw,addr=150.214.224.108)
[root@vcorr1 src]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/devpts /dev/pts devpts rw 0 0
/dev/sda5 /usr ext2 rw 0 0
pcgp:/acroot/usr /mnt nfs rw,addr=pcgp 0 0
nodev /mnt/proc proc rw 0 0
[root@vcorr1 src]# umount /mnt/proc/
umount: nodev: not found
umount: /mnt/proc: not mounted
[root@vcorr1 src]# mount
/dev/sda1 on / type ext2 (rw)
/proc on /proc type proc (rw,0)
/devpts on /dev/pts type devpts (rw)
/dev/sda5 on /usr type ext2 (rw)
pcgp:/acroot/usr on /mnt type nfs (rw,addr=150.214.224.108)
[root@vcorr1 src]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/devpts /dev/pts devpts rw 0 0
/dev/sda5 /usr ext2 rw 0 0
pcgp:/acroot/usr /mnt nfs rw,addr=pcgp 0 0
nodev /mnt/proc proc rw 0 0 <--- still there !
I normally don't use directories which are on NFS mounted drives as mount
points except for one important (for me) case: systems with root on NFS.
That's actually how it started since I first tried the newer kernels on
this kind of machines.
The pattern is more or less always the same, after some time (which is
_apparently_ shorter when doing a lot of lookups like a `du' command on a
large tree), filesystems who have a mount point which is a child of an NFS
mount point become "somewhat" unmounted. The "somewhat" means that an ls
on this mount point shows an empty directory (all my mountpoints are empty
directories I can't say for sure what happens if it's not empty), but if
my cwd is one of the subdirectories of this mount point I still have
access to it.
On the NFS rooted systems I've thus seen disappearing in a random (and
AFAIR variable between reboots) order /proc, /usr, /home and /dev/pts.
The mount point still appears in /etc/mtab (obviously) and in /proc/mounts
(where it stays forever regardless of the number and flavors of umount
incantations I try). An strace of a df command shows that the fstatfs
system call on the mount point returns data from a parent mount point.
This happens independently of the fact that the root file system is NFS or
not (although I have the _impression_ that the phenomenon is harder to
trigger on ext2-rooted systems).
NFS/dcache interaction. I can perform any test on patches, I'm currently
at 2.3.45, which is otherwise very stable with an ext2 fs as root on SCSI
(ncr53c8xx). I've had a look at the patch for 2.3.46 and I don't think
it contains anything nearly related to this problem.
I've been far too verbose already. Hopefully this information will give
sufficient hints to master VFS and NFS hackers.
Gabriel.
-
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/