Skip to contentSkip to conversation

Bind mounts record fstype of none

DISCUSSION Phillip Susi 5 participants 17 messages Oct 30, 2013 – Oct 31, 2013 Util-Linux package

lore
Share & tools
lore
#0 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I came across an old bug filed in debian noting that mount records the fstype for bind mounts as 'none' and this causes df to suppress showing it. This seems like an error to me. The type should be what the actual filesystem type is, and if df wants to suppress showing bind mounts, it should do so based on the bind flag.

Thoughts?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJScSKuAAoJEJrBOlT6nu75tJwIAKk1IQyvsQIpPUj9ugSrHVDp CdsGB5D8VNznUJ+a+AReNp57AGi/UprdCXsWl33yOuz3zjQKNlYaGEMCsN/pSJnq nn+8pJ5GSggPekUh2FO82sLGaEh4y+rMPlN6rwCyOERkP1V+MaYI9Z2KzCrpnpfI LaDm17q1IzpDtJry55Vg+yd0vuJZ3qpfvLUmD4rj/h7N5gt/lXWeSzcUyIIQvHaA IR7Nch1YaA612Tqz0Zf+dews1ERwERNw2+s8BBlsvTW4FzbR5gfMdn3Xzv8WFnTY yr54S7Krrxn7jbBFCF44GQddxptIJ7jjI2GqYIq1D8L9DoTwSIGEk552/y2negc= =k4dY
-----END PGP SIGNATURE-----

#1 lore raw
Quoted 10 lines · Phillip Susi

I came across an old bug filed in debian noting that mount records the fstype for bind mounts as 'none' and this causes df to suppress showing it.  This seems like an error to me.  The type should be what the actual filesystem type is, and if df wants to suppress showing bind mounts, it should do so based on the bind flag.

Thoughts?

yes, df(1) is from coreutils. ;-)

However, latest df(1) will skip such bind mounts per default - but now because of some 'bind' information (which is not available anyway), but just because it skips "duplicates" based on the device numbers. For the same device number, it will output that with the shortest mount point name.
You have to use -a to see all.

Have a nice day,
Berny

#2 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 7 lines · Bernhard Voelker

yes, df(1) is from coreutils. ;-)

However, latest df(1) will skip such bind mounts per default - but now because of some 'bind' information (which is not available anyway), but just because it skips "duplicates" based on the device numbers. For the same device number, it will output that with the shortest mount point name. You have to use -a to see all.

So is mount wrong for recording the filesystem type as 'none' or not?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJScSzwAAoJEJrBOlT6nu7587EH/j35wWxXuNqljBAn9B4fimyd UcTuchJuPoeWg6fmB6XGJB+Zuv/sari8ur/ihVuV+SiC9+MvBYrkoy+xlTW+vmMc B4usMZRvZQK9QW74nvqibDgp2S1mG2iEbpO58oJK2E6ILQoFLNPY2Awuz2VR7LY9 sLxseN4eSzRdPFRiFfzFIaI6s6PO4fvcJceNukO2LIvbhKEhufduTPEJrPKMDIYK OAgmsDm5PUDCITDyyO9YYlZdVm/RxJmRvssdN+WycfsXzYgad+/BAdc0WENtw81R JHg7MciHqNfNBJ5bmlqwnnynud37gWe7dYRLNoMgXDcAMsIwjBL1NsrEpKcmqmk= =05sY
-----END PGP SIGNATURE-----

#3 lore raw
Quoted 6 lines · Phillip Susi
Quoted 5 lines · Bernhard Voelker

yes, df(1) is from coreutils. ;-)

However, latest df(1) will skip such bind mounts per default - but now because of some 'bind' information (which is not available

typo: s/now/not/, of course.

Quoted 5 lines
Quoted 3 lines

anyway), but just because it skips "duplicates" based on the device numbers. For the same device number, it will output that with the shortest mount point name. You have to use -a to see all.

So is mount wrong for recording the filesystem type as 'none' or not?

Where do you see 'none'?

$ df /home
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sdb        10321208 1233056   8563864  13% /home
$ mkdir /tmp/home
$ mount -o bind /home /tmp/home
$ df -a | grep home
/dev/sdb        10321208 1233056   8563864  13% /home
/dev/sdb        10321208 1233056   8563864  13% /tmp/home
$ mount | grep home
/dev/sdb on /home type ext4 (rw,relatime,data=ordered)
/dev/sdb on /tmp/home type ext4 (rw,relatime,data=ordered)
$ grep home /proc/mounts /proc/self/mountinfo /proc/self/mounts
/proc/mounts:/dev/sdb /home ext4 rw,relatime,data=ordered 0 0
/proc/mounts:/dev/sdb /tmp/home ext4 rw,relatime,data=ordered 0 0
/proc/self/mountinfo:40 21 8:16 / /home rw,relatime shared:24 - ext4 /dev/sdb
rw,data=ordered
/proc/self/mountinfo:109 21 8:16 / /tmp/home rw,relatime shared:24 - ext4
/dev/sdb rw,data=ordered
/proc/self/mounts:/dev/sdb /home ext4 rw,relatime,data=ordered 0 0
/proc/self/mounts:/dev/sdb /tmp/home ext4 rw,relatime,data=ordered 0 0

[That was on kernel 3.7.10 of openSUSE-12.3,
mount/df built from {util-linux,coreutils}.git]

Have a nice day,
Berny

#4 lore raw

Hallo, Bernhard,

Du meintest am 30.10.13:

Quoted 4 lines
Quoted 2 lines

So is mount wrong for recording the filesystem type as 'none' or not?

Where do you see 'none'?

df -a -T

Maybe that problem is related to the option "-type"; "bind" is no allowed "type".

Viele Gruesse!
Helmut

#5 lore raw
Quoted 7 lines · Helmut Hullen

Hallo, Bernhard,

Du meintest am 30.10.13:

Quoted 2 lines
Quoted 2 lines

So is mount wrong for recording the filesystem type as 'none' or not?

Quoted 6 lines
Quoted 1 line

Where do you see 'none'?

df -a -T

Maybe that problem is related to the option "-type"; "bind" is no allowed "type".

The fstype of "none" only shows up on older systems where mtab is a regular file and not a symlink to /proc/self/mounts.

Cheers,
Dave

#6 lore raw

Hallo, Dave,

Du meintest am 30.10.13:

[...]

Quoted 9 lines
Quoted 6 lines
Quoted 1 line

Where do you see 'none'?

df -a -T

Maybe that problem is related to the option "-type"; "bind" is no allowed "type".

The fstype of "none" only shows up on older systems where mtab is a regular file and not a symlink to /proc/self/mounts.

Yes - that's the difference on my system ("mtab" is a regular file).

Viele Gruesse!
Helmut

#7 lore raw
In reply to Helmut Hullen
Quoted 6 lines · Helmut Hullen
Quoted 4 lines

Du meintest am 30.10.13:

Quoted 2 lines

So is mount wrong for recording the filesystem type as 'none' or not?

Quoted 6 lines
Quoted 1 line

Where do you see 'none'?

         df -a -T

Maybe that problem is related to the option "-type"; "bind" is no allowed "type".

I don't get that.
Is it possible you hit the "mtab is evil" (TM Kzak) issue?
  http://karelzak.blogspot.de/2011_04_01_archive.html

Have a nice day,
Berny

#8 lore raw
In reply to Bernhard Voelker

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 7 lines · Bernhard Voelker

Where do you see 'none'?

$ df /home Filesystem     1K-blocks    Used Available Use% Mounted
on /dev/sdb        10321208 1233056   8563864  13% /home
$ mkdir /tmp/home
Quoted 8 lines
$ mount -o bind /home /tmp/home
$ df -a | grep home /dev/sdb        10321208 1233056   8563864  13%
/home /dev/sdb        10321208 1233056   8563864  13% /tmp/home
$ mount | grep home /dev/sdb on /home type ext4
(rw,relatime,data=ordered) /dev/sdb on /tmp/home type ext4
(rw,relatime,data=ordered)

I see none in the output of mount and df. Just rebuilt from git head to make sure and still says none.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJScVmZAAoJEJrBOlT6nu75lywH/i+iIcuIC4M2aQ7XD+uPnFmx e4uW3qs94QdJi0ita9OjCgPKS7jWzCgk5+PiUbj8sWtRvol8WTdbl7yh7tcfjuFz tu2TKg84Q9O+7xHVN6CbwyCmq8VCJQTLYB5fs/+OKByDYxzAiANJnh0P7h8Abu++ 4HEAssrfSNFp3mP2urdZl0XLbEXt5lBdN9q1oNVYhyg6Ts/pTtcipg/+keM49uH0 +2QiJrCdKy9zhcIendFx/FCqvoiKXS/Lm4Hetn9qZwU5s2Oqcdf5BVTK3G+dQ7kv pkY1K2dU18lN4osxjNOVcq/DYFGdSY8jHg3+jbLdn3xmxgKENoOKkvpd9Lea9ao= =ta/U
-----END PGP SIGNATURE-----

#9 lore raw
In reply to Phillip Susi

Hallo, Phillip,

Du meintest am 30.10.13:

Quoted 5 lines

I came across an old bug filed in debian noting that mount records the fstype for bind mounts as 'none' and this causes df to suppress showing it. This seems like an error to me. The type should be what the actual filesystem type is, and if df wants to suppress showing bind mounts, it should do so based on the bind flag.

For seeing "bind" I'd prefer

mount

or

mount | grep -w bind

Viele Gruesse!
Helmut

maintainer
#10 lore raw
In reply to Phillip Susi
Quoted 5 lines · Phillip Susi

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I came across an old bug filed in debian noting that mount records the fstype for bind mounts as 'none' and this causes df to suppress

It was explicitly requested by Al Viro to use "none" for some VFS operations years ago (c4966ccb16868fa748009a826340fac9d1b1ce39, 0fae284a7a13d4d2dba7a908e0662a6d9c46f877).

I think it's correct, because FS type does not make any sense there and it's waste of time to try to determine FS type for MS_BINS or MS_PROPAGATION operations.

Quoted 3 lines

showing it. This seems like an error to me. The type should be what the actual filesystem type is, and if df wants to suppress showing bind mounts, it should do so based on the bind flag.

Seems like you're victim of the mtab file. My Fedora 19:

    # mount --bind /home /mnt/test
    # mount | grep /mnt/test
    /dev/sda5 on /mnt/test type ext4 (rw,relatime,data=ordered)

Karel

Signature · 2 lines
 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com
#11 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 7 lines · Karel Zak
Quoted 5 lines · Phillip Susi

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

I came across an old bug filed in debian noting that mount records the fstype for bind mounts as 'none' and this causes df to suppress

Quoted 7 lines

It was explicitly requested by Al Viro to use "none" for some VFS operations years ago (c4966ccb16868fa748009a826340fac9d1b1ce39, 0fae284a7a13d4d2dba7a908e0662a6d9c46f877).

I think it's correct, because FS type does not make any sense there and it's waste of time to try to determine FS type for MS_BINS or MS_PROPAGATION operations.

How does it not make sense?

Quoted 8 lines
Quoted 3 lines

showing it. This seems like an error to me. The type should be what the actual filesystem type is, and if df wants to suppress showing bind mounts, it should do so based on the bind flag.

Seems like you're victim of the mtab file. My Fedora 19:

# mount --bind /home /mnt/test # mount | grep /mnt/test /dev/sda5
on /mnt/test type ext4 (rw,relatime,data=ordered)

Since the kernel reports the correct type, then I'd say mount should behave the same when using mtab, and record it right instead of forcing it to none.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJScmawAAoJEJrBOlT6nu75B6cIAMHuRn7YaD6ZO2oS0e68RlyO FGBNVkiUezG/cw8GBxihiSejlZP99cR0VMeD7ImLjLpuKbJ/tOdqHUGIFneDZu6I hBz7luqVTnyOiimEaX8AXMWy4LOZzXiFd/etWTG9QpePsj+e+NRGj826cXmEpYoX uIuWze+IRZc7NLzb+TmTtJcv/2a6yFZHxIdTt9SYzsPWWJ23m+t9GWtTbMt4CnXZ 04BxJpryA04KoZhJBeliHu87xQ5cQBOfZkBavx2rpoGoiQRez9XVorif3hP7SBwT KD370LQr0GWbTQo1YEuIHXGaAcqEW/yQcPWKmekJXkg+1dhgE5c8Rvly37jeKRs= =+osw
-----END PGP SIGNATURE-----

maintainer
#12 lore raw
Quoted 15 lines · Phillip Susi

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 11 lines · Karel Zak
Quoted 5 lines · Phillip Susi

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

I came across an old bug filed in debian noting that mount records the fstype for bind mounts as 'none' and this causes df to suppress

It was explicitly requested by Al Viro to use "none" for some VFS operations years ago (c4966ccb16868fa748009a826340fac9d1b1ce39, 0fae284a7a13d4d2dba7a908e0662a6d9c46f877).

Quoted 5 lines
Quoted 3 lines

I think it's correct, because FS type does not make any sense there and it's waste of time to try to determine FS type for MS_BINS or MS_PROPAGATION operations.

How does it not make sense?

It is not FS operation, FS type is completely irrelevant here, kernel does not use this argument of the mount(2) syscall.

Quoted 4 lines
Quoted 4 lines
Quoted 3 lines

showing it. This seems like an error to me. The type should be what the actual filesystem type is, and if df wants to suppress showing bind mounts, it should do so based on the bind flag.

Quoted 8 lines
Quoted 4 lines

Seems like you're victim of the mtab file. My Fedora 19:

# mount --bind /home /mnt/test # mount | grep /mnt/test /dev/sda5
on /mnt/test type ext4 (rw,relatime,data=ordered)

Since the kernel reports the correct type, then I'd say mount should behave the same when using mtab, and record it right instead of forcing it to none.

There is *many disadvantages* when you use mtab, not sure if it make sense to fix the issues especially when mtab is currently unused by (almost) all distributions.

Maybe we can keep the fstype and not replace it with "none" for mtab, but is it so important when we use "none" since 2009 and mtab is almost dead?

Karel

Signature · 2 lines
 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com
#13 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 7 lines · Karel Zak

There is *many disadvantages* when you use mtab, not sure if it make sense to fix the issues especially when mtab is currently unused by (almost) all distributions.

Maybe we can keep the fstype and not replace it with "none" for mtab, but is it so important when we use "none" since 2009 and mtab is almost dead?

I know there were a number of issues with this transition, have they all been worked out at this point? Is all you need to do to make the switch is replace /etc/mtab with a symlink to /proc/mounts? Maybe I'll try doing that.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJScnc5AAoJEJrBOlT6nu75HBEH/i7nKpCaq7TkgArB0IgnmSqM fHkp1jMIltOxkfVDj8ma6hErYUJ+2g4abgKF8nrP39NWiFldrCBqTjOAr2kOl9wn jO40x9ur6SJQpVbSrmtHOam05J+P09N2SRXb/LAVIsUzTyIvw3kBFaGpl0ElJz8Q Jf3yTWr5gPyR14oAdOKdzkW70rktob2lRGM4DetChQd8H0LtfiaODtaBSbDyJMQ7 P8ErR42Isosf2+RBW+c/EC3biE82QsMcJjMP4eJ+A3uG8ZMlOTtDpthvMjQPY6+0 xCBz9Qd9yjvfgGTxnuV+AyX9Xa+mQNdS4/MtvyCwTF3TTKekhkYMK2CMSJ9gSdI= =OpPE
-----END PGP SIGNATURE-----

maintainer
#14 lore raw
Quoted 8 lines · Phillip Susi

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 4 lines · Karel Zak

There is *many disadvantages* when you use mtab, not sure if it make sense to fix the issues especially when mtab is currently unused by (almost) all distributions.

Quoted 8 lines
Quoted 3 lines

Maybe we can keep the fstype and not replace it with "none" for mtab, but is it so important when we use "none" since 2009 and mtab is almost dead?

I know there were a number of issues with this transition, have they all been worked out at this point? Is all you need to do to make the switch is replace /etc/mtab with a symlink to /proc/mounts? Maybe I'll try doing that.

Yes, the symlink and libmount based mount(8). We had some issues with df(1) but I guess all is resolved by recent coreutils.

Karel

Signature · 2 lines
 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com
maintainer
#15 lore raw
In reply to Phillip Susi
Quoted 8 lines · Phillip Susi

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 4 lines · Karel Zak

There is *many disadvantages* when you use mtab, not sure if it make sense to fix the issues especially when mtab is currently unused by (almost) all distributions.

Quoted 8 lines
Quoted 3 lines

Maybe we can keep the fstype and not replace it with "none" for mtab, but is it so important when we use "none" since 2009 and mtab is almost dead?

I know there were a number of issues with this transition, have they all been worked out at this point? Is all you need to do to make the switch is replace /etc/mtab with a symlink to /proc/mounts? Maybe I'll try doing that.

... and it's also good to link mount.nfs from nfs-utils with libmount as NFS maintains some mount options in userspace (in this case we use private library /run/mount/utab file).

Karel

Signature · 2 lines
 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com
maintainer
#16 lore raw
In reply to Phillip Susi
Quoted 1 line · Phillip Susi
Quoted 1 line
Quoted 1 line

I came across an old bug filed in debian

I forgot... Thanks! We had very good relationship with Debian (thanks to LaMont Jones), but in last 5 years it seems that nobody from Debian camp cares. It's strange as Debian plays important role in Linux world.

Karel

Signature · 2 lines
 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com