On 10/30/2014 05:59 AM, Pádraig Brady wrote: > On 10/30/2014 03:44 AM, Pádraig Brady wrote: >> On 10/30/2014 02:23 AM, Bernhard Voelker wrote: >>> 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. > > A compromise would be to list the separate exports by default > since this is what people are used to, and suppress them > in --total mode to support showing the individual file systems > which are available and to have an accurate total in that case.
I somehow don't like the idea that local file systems are treated differently than remote ones. I'm either for showing all or none of the duplicates. So going back again to where the whole story began, that was a) massive bind mounts or duplicate NFS mounts on servers where the block and inode statistics is redundant and (in case of remote file systems) can take some time, and b) users complaining about bind-mounted tmpfs file systems on newer distributions being shown several times. I think as long as tmpfs is not treated as a dummy file system and as such elided in the default output, case b) is a strong argument to favor filtering duplicities, because modern Linux system have 5+ such tmpfs mounts. Avoiding further stat()/statfs() on duplicate remote file systems is another more than nice feature. After all I think the current filtering is the right thing. And if using libmount to securely detecting over-mounting etc. is helping in the remaining edge cases, then I think we're done. I think getting a clean list of mountinfo with the over-mounted ones removed could be determined like in "findmnt -U": http://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/misc-utils/findmnt.c?id=8fc4a88630#n1519 mnt_table_uniq_fs(tb, MNT_UNIQ_KEEPTREE, uniq_fs_target_cmp); A side note regarding --total: strictly spoken we'd also have to avoid adding the space for loop mounts, because the underlying space is already counted. OTOH the "avail" column is still correct (and showing free space is the main purpose of df(1) according to POSIX). Thanks & have a nice day, Berny
