On 2014-09-09 16:07, Bernhard Voelker wrote:
On 09/09/2014 02:51 PM, Carlos E. R. wrote:
when I do a "df -h", there is at least one partition that is missing from the output.
For clarity, I'll use "grep" for the paste here, but the long "df" output has the same problem.
cer@Telcontar:~> mount | grep storage /dev/sdd2 on /data/storage_d type xfs (rw,relatime,attr2,inode64,noquota) /dev/sda12 on /data/storage_a type xfs (rw,relatime,attr2,inode64,noquota) /dev/sdb11 on /data/storage_b type reiserfs (rw,relatime,user_xattr,acl) /dev/sdc18 on /data/storage_c type xfs (rw,relatime,attr2,inode64,noquota)
cer@Telcontar:~> df -h | grep storage /dev/sdd2 1,9T 1,9T 13G 100% /data/storage_d /dev/sda12 314G 168G 147G 54% /data/storage_a /dev/sdb11 384G 313G 71G 82% /data/storage_b cer@Telcontar:~>
As you see, "/data/storage_c" is mounted, but it is not listed in "df". Asking for it explicitly produces the expected output:
cer@Telcontar:~> df -h /data/storage_c Filesystem Size Used Avail Use% Mounted on /dev/sdc18 546G 400G 146G 74% /data/storage_c cer@Telcontar:~>
I don't remember seeing this before :-?
In the upstream coreutils-v8.23, there were several fixes regarding such "filtering of duplicate mounts" (like e.g. bind mounts or mounting the a NFS volume of the same underlying file system on the server). But your case looks quite straight-forward.
There is a subdirectory of /data/storage_c which is served via nfs. It can be mounted locally, manually, for testing. The entry in fstab is commented out. And there is a bind mount: /data/storage_c/partimag /data/partimag none bind 0 0 cer@Telcontar:~> mount | grep partimag /dev/sdc18 on /data/partimag type xfs (rw,relatime,attr2,inode64,noquota) cer@Telcontar:~> df -h | grep partimag /dev/sdc18 546G 424G 123G 78% /data/partimag cer@Telcontar:~> Telcontar:~ # umount /data/partimag Telcontar:~ # cer@Telcontar:~> df -h | grep storage /dev/sdd2 1,9T 1,7T 136G 93% /data/storage_d /dev/sda12 314G 168G 147G 54% /data/storage_a /dev/sdb11 384G 313G 71G 82% /data/storage_b /dev/sdc18 546G 424G 123G 78% /data/storage_c cer@Telcontar:~> So that was it! - :-o (surprise)
This should only happen when the same file system has already been processed. Please give us the output of
$ stat -c '%n %m %d' /data/storage_{a,b,c,d}
cer@Telcontar:~> stat -c '%n %m %d' /data/storage_{a,b,c,d} /data/storage_a /data/storage_a 2060 /data/storage_b /data/storage_b 2075 /data/storage_c /data/storage_c 66306 /data/storage_d /data/storage_d 2098 cer@Telcontar:~> That was before umounting the bind mount. Repeating now I get: cer@Telcontar:~> stat -c '%n %m %d' /data/storage_{a,b,c,d} /data/storage_a /data/storage_a 2060 /data/storage_b /data/storage_b 2075 /data/storage_c /data/storage_c 66306 /data/storage_d /data/storage_d 2098 cer@Telcontar:~> which is unchanged. What did you expect to see there? :-? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)