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)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-09-09 18:04, Bernhard Voelker wrote:

On 09/09/2014 04:28 PM, Carlos E. R. wrote:

...

So that was it! - :-o (surprise)

Ah, that's it: as the string "/data/storage_c" is longer than "/data/partimag" (15 vs. 14 chars), df(1) has chosen to take the latter.

Wow. I'm bewildered. I replaced /data/partimag with /data/partimage, mounted it, and the output keeps displaying storage_c... and not partimag* Then I short the name again by one char, and storage_c disappears and partimag reapears... And the new coreutils would display both entries? - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQPVecACgkQtTMYHG2NR9W8DwCaA9hrZkvMT4Hlj8dvgdQBzJhU mE4An3ybkGrvfmIkhANmnqOXyvZNO9mP =Gqsh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org