Re: [PATCH] df: avoid suppressing remote mounts of separate exports

[Pádraig Brady]

On 10/30/2014 02:23 AM, Bernhard Voelker wrote:
> On 10/29/2014 04:40 AM, Pádraig Brady wrote:
>> * src/df.c (filter_mount_list): Separate remote locations may
>> have different ACLs etc. so list each even if they share
>> the same remote device and thus storage.
>> * NEWS: Mention the change in behavior.
>>
>> Reported in http://bugs.debian.org/737399
>> Reported in http://bugzilla.redhat.com/920806
> 
> There've been some tickets for openSUSE in the last 2 years
> regarding such suppressing, too.
> TBH, I don't remember exactly why we have chosen to try to
> suppress _all_ duplicate file systems - I think the whole story
> began with massive bind mounting on a user's server.
> And we extended the filtering to remote file system types as well.
> It has become a personal point of view whether duplicate file
> systems should be shown by df(1) or not. The only argument pro
> suppressing is the --total option which would add up the space
> several times.
> 
> Regarding your argument to remove it - the ACLs: I don't see
> what they have much to do with file system statistics as df(1)
> shows it ... well, in a corner case a mount point could be
> ACLed so that the user cannot access the directory while the
> other mount point would still be visible. Did you mean that?

Yes. Also one could be read-only and another writeable.
Though you're right that these are only loosely related to
the statistics presented by df.  I was also considering quotas,
though they're associated with the underlying device
rather than associated with particular exports.

> After all, I don't have a strong preference, so I'm probably
> okay with re-introducing duplicate remote file systems.

I'm 50:50 too. In that case we should probably err
on the side of less code and edge cases.
I.E. not go with with patch.

> I didn't have a closer look at the code yet, but I was really
> puzzled because no test has changed neither for the other
> df-patch nor for this one.

Yes I should add a test.  I can trigger remoteness by including
a ':' in the device name.  Actually I see now that the new
libmount code in gnulib doesn't use that and only goes on
an incomplete set of file system types as returned by statfs.
I should fix that up also.

> A quick look at the patch made me think about a case which
> is still not handled and indeed now produces wrong output:
> when a remote file system is over-mounted by a local one.
> IMO the loop has to be split: first build the list of mount
> entries which are 'visible' to the user (i.e., not over-mounted
> nor otherwise inaccessible due to permissions etc.), and then
> eliminating the duplicate - maybe only !me_remote - ones
> according to shorter names etc.

Discounting remoteness for now, we may be able to leverage
the device IDs that will be coming from /proc/self/mountinfo
to better distinguish overmounted devices.  That will be
coming when we update to the latest gnulib.

thanks,
Pádraig.