Re: mount -f regression in v2.21's new-mount

["Pádraig Brady" <P@draigBrady.com>]

On 03/12/2012 02:32 PM, Karel Zak wrote:
> On Sun, Mar 11, 2012 at 07:06:26PM +0000, Matt Burgess wrote:
>> On Fri, 2012-03-09 at 13:29 +0100, Karel Zak wrote:
>>> On Fri, Mar 09, 2012 at 04:30:02AM -0700, Matthew Burgess wrote:
>>>> On Fri, 9 Mar 2012 11:53:04 +0100, Karel Zak <kzak@redhat.com> wrote:
>>>>> On Thu, Mar 08, 2012 at 08:25:00PM +0000, Matt Burgess wrote:
>>>>>> I've attached LIBMOUNT_DEBUG output from the 'mount -a' call that our
>>>>>> bootscript does.  Note how mount correctly detects that /proc, /sys
>>>>>
>>>>>  No, it calls mount(2) syscall for /proc. The problem is that the
>>>>>  detection code expects /proc/self/mountinfo (used on systems with
>>>>>  mtab -> /proc/mounts symlink), but your system uses regular mtab.
>>>>>
>>>>>  I'll fix it. Thanks.
>>>
>>>  Fixed, try git pull.
>>
>> Thanks, that's sorted it!
>>>
>>>> Thanks!  Is there a consensus opinion on whether users should be
>>>> using a regular mtab or a symlink to /proc/self/mountinfo?
>>>
>>>  - disadvantage is that some userspace utils (e.g. df(1) are not able
>>>    to de-duplicate list of mounted filesystem (bind mounts))
>>>
>>>  + advantage is that there is only one list of mounted filesystems
>>>    with always valid mount options (on systems with mtab is not problem
>>>    to have 'rw' in mtab for read-only NFS, etc.), no problems with
>>>    namespaces, not writable files in /etc, no mtab lock, etc.
>>>
>>>  The symlink is required for systemd.
>>
>> Thanks for the info.  Looks like there are more advantages than
>> disadvantages.  Without wishing to stray too far off-topic, do you know
>> if the Coreutils folks are aware of/looking at the 'df' issue?

Well we know about it.
I've not looked at it as I was holding out hope
that those that changed the interface might know
how to handle it, and propose a fix.

>  My wish:
> 
>     - add FS de-duplicate function to libmount 
>     - add SIZE, USE, AVAILABLE, USE% columns to findmnt
>     - add --df to findmnt
>     - try to implement df(1) compatible output if findmnt argv[0] is
>       df ;-)))

That sounds like a bit of an extreme solution,
which doesn't help any other processes that want
to query file systems like df does.
For example is `stat %m` handled OK these days?

Is there really no way to know if something is a bind mount?
For example they were handled fine with some heuristics
before this symlink was introduced:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=0380e4c9
Could we perhaps depend on the order of returned entries.

cheers,
Pádraig.