Activity log for bug #1432871

Date Who What changed Old value New value Message
2015-03-16 22:45:26 Dave Chiluk bug added bug
2015-03-16 23:34:36 Dave Chiluk attachment added lp1432871.trusty.debdiff https://bugs.launchpad.net/ubuntu/+bug/1432871/+attachment/4347456/+files/lp1432871.trusty.debdiff
2015-03-17 00:18:28 Ubuntu Foundations Team Bug Bot tags cts cts patch
2015-03-17 00:18:35 Ubuntu Foundations Team Bug Bot bug added subscriber Ubuntu Sponsors Team
2015-03-22 04:48:27 Dave Chiluk attachment removed lp1432871.trusty.debdiff https://bugs.launchpad.net/ubuntu/+bug/1432871/+attachment/4347456/+files/lp1432871.trusty.debdiff
2015-03-22 04:49:16 Dave Chiluk attachment added lp1432871.trusty.debdiff https://bugs.launchpad.net/ubuntu/+bug/1432871/+attachment/4351938/+files/lp1432871.trusty.debdiff
2015-04-03 10:09:29 Sebastien Bacher affects ubuntu coreutils (Ubuntu)
2015-04-03 10:11:41 Sebastien Bacher removed subscriber Ubuntu Sponsors Team
2015-04-08 13:32:09 Dave Chiluk nominated for series Ubuntu Trusty
2015-04-08 13:32:09 Dave Chiluk nominated for series Ubuntu Vivid
2015-04-08 13:32:09 Dave Chiluk nominated for series Ubuntu Utopic
2015-07-22 22:13:46 Dave Chiluk coreutils (Ubuntu): importance Undecided Low
2015-07-22 22:24:48 Dave Chiluk description Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount <snip> 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip> [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - This is a change of behavior from precise * Explanation - This patch checks to see if the source directory of a mount is contains the destination directory of the mount it's replacing *(check if it's bind mount from the original directory). [Test Case] * $ mount <snip> 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip> [Regression Potential] * Patch is not upstream, and will not be upstreamed *(see other info) * df command could stop working if I wrote the patch poorly. df might not process mounts correctly. [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and likely significantly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. * Theoretically df, mount and a number of other commands could be modified to run ioctl commands to determine if the mount is from a root inode of the mounted filesystem to determine preference, but that is really more of an upstream exercise. Original bug. ________________________________________________________________________ Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount <snip> 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip>
2015-07-22 22:26:18 Dave Chiluk bug added subscriber Ubuntu Sponsors Team
2015-08-14 15:23:48 Dave Chiluk description [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - This is a change of behavior from precise * Explanation - This patch checks to see if the source directory of a mount is contains the destination directory of the mount it's replacing *(check if it's bind mount from the original directory). [Test Case] * $ mount <snip> 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip> [Regression Potential] * Patch is not upstream, and will not be upstreamed *(see other info) * df command could stop working if I wrote the patch poorly. df might not process mounts correctly. [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and likely significantly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. * Theoretically df, mount and a number of other commands could be modified to run ioctl commands to determine if the mount is from a root inode of the mounted filesystem to determine preference, but that is really more of an upstream exercise. Original bug. ________________________________________________________________________ Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount <snip> 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip> [Impact]  * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory.  * justification - This is a change of behavior from precise  * Explanation - This patch checks to see if the source directory of a mount is contains the destination directory of the mount it's replacing *(check if it's bind mount from the original directory). [Test Case]  * $ mount <snip> 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip> [Regression Potential]  * Patch is not upstream, and will not be upstreamed *(see other info)  * df command could stop working if I wrote the patch poorly. df might not process mounts correctly. [Other Info]  * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and likely significantly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts.  * Theoretically df, mount and a number of other commands could be modified to run ioctl commands to determine if the mount is from a root inode of the mounted filesystem to determine preference, but that is really more of an upstream exercise. Original bug. ________________________________________________________________________ Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount <snip> 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip>
2015-08-18 20:37:14 Dave Chiluk attachment removed lp1432871.trusty.debdiff https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4351938/+files/lp1432871.trusty.debdiff
2015-08-18 20:37:57 Dave Chiluk attachment added lp1432871.trusty.debdiff https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4447737/+files/lp1432871.trusty.debdiff
2015-08-18 21:13:02 Adam Conrad coreutils (Ubuntu): status New Won't Fix
2015-08-18 21:22:45 Adam Conrad removed subscriber Ubuntu Sponsors Team
2015-08-21 05:00:26 Mathew Hodson coreutils (Ubuntu): milestone trusty-updates
2015-08-25 15:10:06 Dave Chiluk coreutils (Ubuntu): status Won't Fix Incomplete
2015-09-21 19:28:39 Dave Chiluk attachment removed lp1432871.trusty.debdiff https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4447737/+files/lp1432871.trusty.debdiff
2015-10-02 20:14:31 Dave Chiluk nominated for series Ubuntu Vivid
2015-10-02 20:14:31 Dave Chiluk nominated for series Ubuntu Wily
2015-10-02 20:14:31 Dave Chiluk nominated for series Ubuntu Trusty
2015-10-02 22:01:35 Dave Chiluk attachment added lp1432871.wily.debdiff https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4482367/+files/lp1432871.wily.debdiff
2015-10-02 22:19:50 Dave Chiluk description [Impact]  * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory.  * justification - This is a change of behavior from precise  * Explanation - This patch checks to see if the source directory of a mount is contains the destination directory of the mount it's replacing *(check if it's bind mount from the original directory). [Test Case]  * $ mount <snip> 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip> [Regression Potential]  * Patch is not upstream, and will not be upstreamed *(see other info)  * df command could stop working if I wrote the patch poorly. df might not process mounts correctly. [Other Info]  * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and likely significantly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts.  * Theoretically df, mount and a number of other commands could be modified to run ioctl commands to determine if the mount is from a root inode of the mounted filesystem to determine preference, but that is really more of an upstream exercise. Original bug. ________________________________________________________________________ Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount <snip> 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip> [Impact]  * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory.  * justification - This is a change of behavior from precise  * Explanation - This patch checks to see if the source directory of a mount is contains the destination directory of the mount it's replacing *(check if it's bind mount from the original directory). [Test Case]  * $ mount <snip> 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip> [Regression Potential]  * Patch is upstreamed.  * df command now relies on /proc/self/mountinfo [Other Info]  * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. Original bug. ________________________________________________________________________ Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount <snip> 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip>
2015-10-02 22:22:24 Dave Chiluk description [Impact]  * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory.  * justification - This is a change of behavior from precise  * Explanation - This patch checks to see if the source directory of a mount is contains the destination directory of the mount it's replacing *(check if it's bind mount from the original directory). [Test Case]  * $ mount <snip> 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip> [Regression Potential]  * Patch is upstreamed.  * df command now relies on /proc/self/mountinfo [Other Info]  * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. Original bug. ________________________________________________________________________ Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount <snip> 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip> [Impact]  * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory.  * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount.  * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case]  * $ mount <snip> 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip> [Regression Potential]  * Patch is upstreamed.  * df command now relies on /proc/self/mountinfo [Other Info]  * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. Original bug. ________________________________________________________________________ Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount <snip> 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip>
2015-10-02 22:42:07 Dave Chiluk description [Impact]  * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory.  * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount.  * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case]  * $ mount <snip> 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip> [Regression Potential]  * Patch is upstreamed.  * df command now relies on /proc/self/mountinfo [Other Info]  * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. Original bug. ________________________________________________________________________ Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount <snip> 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip> [Impact]  * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory.  * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount.  * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case]  * $ mount <snip> 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip> [Regression Potential]  * Patch is upstreamed.  * df command now relies on /proc/self/mountinfo [Other Info]  * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. * In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. ________________________________________________________________________ Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount <snip> 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) <snip> /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b </snip> I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on <snip> /dev/sdc5 449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid <snip>
2015-10-03 02:50:18 Dave Chiluk coreutils (Ubuntu): status Incomplete In Progress
2015-10-05 18:58:23 Brian Murray bug task added coreutils (Ubuntu Wily)
2015-10-13 14:36:04 Dave Chiluk bug added subscriber Ubuntu Sponsors Team
2015-10-14 14:44:28 Chris J Arges bug task added coreutils (Ubuntu Trusty)
2015-10-14 14:44:56 Chris J Arges bug task added coreutils (Ubuntu Vivid)
2015-10-14 17:22:13 Michael Terry bug added subscriber Michael Terry
2015-10-14 18:38:00 Launchpad Janitor branch linked lp:ubuntu/wily-proposed/coreutils
2015-10-14 20:19:13 Dave Chiluk coreutils (Ubuntu Vivid): assignee Dave Chiluk (chiluk)
2015-10-14 20:19:15 Dave Chiluk coreutils (Ubuntu Trusty): assignee Dave Chiluk (chiluk)
2015-10-15 09:46:21 Launchpad Janitor coreutils (Ubuntu Wily): status In Progress Fix Released
2015-10-19 15:58:53 Dave Chiluk coreutils (Ubuntu Vivid): status New In Progress
2015-10-19 15:58:55 Dave Chiluk coreutils (Ubuntu Trusty): status New In Progress
2015-10-19 15:59:04 Dave Chiluk coreutils (Ubuntu Wily): status Fix Released Fix Committed
2015-10-19 16:05:08 Dave Chiluk coreutils (Ubuntu Wily): status Fix Committed Fix Released
2015-10-26 15:01:04 Michael Terry bug added subscriber Ubuntu Stable Release Updates Team
2015-11-03 20:16:38 Mathew Hodson coreutils (Ubuntu Trusty): importance Undecided Low
2015-11-03 20:16:39 Mathew Hodson coreutils (Ubuntu Vivid): importance Undecided Low
2015-11-04 17:39:00 Chris J Arges coreutils (Ubuntu Vivid): status In Progress Fix Committed
2015-11-04 17:39:03 Chris J Arges bug added subscriber SRU Verification
2015-11-04 17:39:07 Chris J Arges tags cts patch cts patch verification-needed
2015-11-04 17:39:19 Chris J Arges removed subscriber Ubuntu Sponsors Team
2015-11-05 21:13:34 Dave Chiluk attachment added trusty.debdiff https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4513696/+files/lp1432871.trusty.debdiff
2015-11-05 22:44:49 Dave Chiluk tags cts patch verification-needed cts patch verification-done-vivid verification-done-wily
2015-11-11 21:01:57 Launchpad Janitor coreutils (Ubuntu Vivid): status Fix Committed Fix Released
2015-11-11 21:02:01 Chris J Arges removed subscriber Ubuntu Stable Release Updates Team
2015-11-11 22:05:11 Dave Chiluk bug added subscriber Ubuntu Stable Release Updates Team
2015-11-11 22:06:31 Dave Chiluk bug added subscriber Ubuntu Sponsors Team
2015-11-13 10:44:49 Martin Pitt removed subscriber Ubuntu Sponsors Team
2015-11-16 16:29:44 Chris J Arges coreutils (Ubuntu Trusty): status In Progress Fix Committed
2015-11-16 16:29:51 Chris J Arges tags cts patch verification-done-vivid verification-done-wily cts patch verification-done-vivid verification-done-wily verification-needed
2015-11-16 17:54:07 Dave Chiluk attachment added fixftbfs.debdiff https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4520226/+files/fixftbfs.debdiff
2015-11-16 18:07:01 Dave Chiluk attachment removed fixftbfs.debdiff https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4520226/+files/fixftbfs.debdiff
2015-12-03 16:02:35 Dave Chiluk attachment added Fix total-unprocessed testcase https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4529108/+files/lp1432871_ftbfs_trusty.debdiff
2015-12-03 16:23:06 Dave Chiluk attachment removed Fix total-unprocessed testcase https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4529108/+files/lp1432871_ftbfs_trusty.debdiff
2015-12-03 16:41:23 Dave Chiluk attachment added lp1432871_ftbfs_trusty.debdiff https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4529111/+files/lp1432871_ftbfs_trusty.debdiff
2015-12-03 18:37:40 Dave Chiluk tags cts patch verification-done-vivid verification-done-wily verification-needed cts patch verification-done verification-done-trusty verification-done-vivid verification-done-wily
2015-12-10 20:42:48 Launchpad Janitor coreutils (Ubuntu Trusty): status Fix Committed Fix Released
2017-07-12 18:42:25 Eric Jensen bug added subscriber Eric Jensen