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.
