Below is the output from mount. The IP field is masked (for security). Also
real volume names were replaced with 'data'.
appnfs3:/home-7a/dev on /home type nfs
(ro,rsize=8192,timeo=14,intr,addr=A.B.C.D)
appnfs1:/home-2a/dev/sb on /dist/2a type nfs
(rw,noexec,noatime,rsize=8192,timeo=14,intr,addr=A.B.C.D)
appnfs1:/home-5a/dev/sb on /dist/5a type nfs
(rw,noexec,noatime,rsize=8192,timeo=14,intr,addr=A.B.C.D)
appnfs3:/home-7a/dev/sb on /dist/7a type nfs
(rw,noexec,noatime,rsize=8192,timeo=14,intr,addr=A.B.C.D)
appnfs2:/home-0a/bootconfig/data on /dist/0a type nfs
(ro,noexec,noatime,rsize=8192,timeo=14,intr,addr=A.B.C.D)
/dist/2a on /home/data type none (rw,bind)
/dist/5a on /home/data type none (rw,bind)
/dist/7a on /home/data type none (rw,bind)
The 'mount' commmand that was used to create /dist/*. The mount was issued in a
processed cloned with a new namespace.
mount --bind "$NEW_MOUNT" "$MOUNT_ON"
E.g.:
Mount --bind /home/data /dist/7a
The output from df with -T or -P below. Both report incorrect mount point.
$ df -T /home/data
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dist/2a none 258144000 98648544 159495456 39% /home/data
$ df -P /home/data
Filesystem 1024-blocks Used Available Capacity Mounted on
/dist/2a 258144000 98648544 159495456 39% /home/data
$ df -TP /home/data
Filesystem Type 1024-blocks Used Available Capacity Mounted on
/dist/2a none 258144000 98648544 159495456 39% /home/data
I also run a 'stat' (using perl):
$ perl -e 'print join(",", stat("/home/data/")), "\n";'
22,13,16877,10,0,0,0,1024,1248984894,1257439238,1257439238,32768,16
I did 'strace' on the 'df' process. From the output, it looks as if the
following logic was used:
Run 'fstat64' on the named parameter.
Read the mtab table
Run 'lstat64' on each component /home, /home/data/, ...
I suspect that at this point, a search on done on all the entries in mtab for
the best match
The "mount" man page (on my system) says:
When the proc filesystem is mounted (say at /proc), the files
/etc/mtab and /proc/mounts have very similar contents. The former has
somewhat more information, such as the mount options used, but is not
necessarily up-to-date (cf. the -n option below). It is possible to
replace /etc/mtab by a symbolic link to /proc/mounts, but some infor-
mation is lost that way, and in particular working with the loop
device will be less convenient, and using the "user" option will fail.
As a quick alternative - On Linux - if the code was using the '/proc/mounts' to
match the file name with the mounted file system, it will not get confused by
the extra mount point that belong to other processes in other name spaces. I
could not find any other system call that will provide extra information about
mount points. Unfortunantely, I do not have the option to reconfigure the
system.
Thanks again for looking into this:
Yair
-----Original Message-----
From: Bauke Jan Douma [mailto:bjdo...@xs4all.nl]
Sent: Saturday, January 02, 2010 9:57 AM
To: Lenga, Yair [ICG-MKTS]; bug-coreutils@gnu.org
Subject: Re: Problem with 'df' on RedHat Linux with multiple "namespaces"
Bob Proulx wrote on 01/01/2010 03:18 AM:
> Pádraig Brady wrote:
>> Lenga, Yair wrote:
>>> Please let me know if you need additional information.
>> I'm not sure it's related but could you give the output from df -P as
>> the -P option should always be used from scripts.
>
> Seeing the output from the 'mount' command would also be useful.
>
> $ mount
>
> And perhaps the 'df -T' output.
>
> $ df -TP
>
> Bob
>
>
>
>
Not really related, but...
Coreutils' df's header line says 'use%' (en_US.UTF-8 locale). That column then
lists values such as '55%', etc. i.e. a number with a percentage tacked to it.
To me, that's a mismatch. The answer to the question '55 out of 100 -- what's
the percentage?" is "55", not "55 percent".
I find it more logical for the header to have "use" instead of 'use%', while
the values retain their percentage-character.
bjd
