coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bernhard Voelker
Subject: Re: [PATCH] df: avoid suppressing remote mounts of separate exports
Date: Fri, 31 Oct 2014 01:52:49 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]