Re: [RFC] New attempt to a better "btrfs fi df"

["Michael Kjörling" <michael@kjorling.se>]

On 27 Oct 2012 23:38 +0100, from hugo@carfax.org.uk (Hugo Mills):
>>>            Data: RAID 0   System: RAID 1   Unused
>>> /dev/vdb     307.25 MB                -        2.23 GB
>>> /dev/vdc     307.25 MB             8 MB        2.69 GB
>>> /dev/vdd     307.25 MB             8 MB        2.24 GB
>>>            ============   ==============   ============
>>> TOTAL        921.75 MB            16 MB        7.16 GB
>> 
>> It would scale better with the number of drives and there is a good way to 
>> place the totals.
> 
>    Note that this could get arbitrarily wide in the presence of the
> (planned) per-object replication config. Otherwise, it works. The
> width is probably likely to grow more slowly than the length, though,
> so this way round is probably the better option. IMO. Eggshell blue is
> good enough. :)

Of course, but the suggestion in the mail I replied to can get equally
arbitrarily wide in the presence of a large number of _drives_.

In my experience, many times it's better to put something together
that works with the current status of the project and start using it,
than trying to shoehorn every "we'd like to do this some day" feature
into the original design. _Particularly_ when it's UI one is talking
about. I can think of a few ways it might be possible to restrict the
growth of the width of a table like this even in the face of separate
per-object replication settings, the most obvious probably being to
keep a tally on disk for each of the replication types, and have
columns for each replication configuration (so you might get one
column for RAID 0 data, one for RAID 1 data, one for SINGLE data, and
so on, but you'll _never_ get more "data" columns than the filesystem
itself supports replication methods for "data" data; the tally simply
being an optimization so you don't have to scan the whole file system
for a simple "df"), but by the time that feature gets implemented,
maybe someone can think of a better presentation.

After all, UI aspects tend to be the easiest to fiddle with.

Organizing the drives in rows also has the advantage that you don't
_have_ to read everything before you can start printing the results,
if you can live with the constraint of supporting only one data and
metadata replication strategy. Whether to implement it that way is
another matter. With large storage systems and multi-CPU/multi-core
systems, while a multithreaded approach might not provide consistent
device ordering between executions depending on the exact thread
execution order, it could provide a fair performance enhancement. And
forget KISS; don't we all _love_ a chance to do a little multithreaded
programming before coffee if it saves the poor sysadmin a few dozen
milliseconds per "df"? ;-)

-- 
Michael Kjörling • http://michael.kjorling.se • michael@kjorling.se
                “People who think they know everything really annoy
                those of us who know we don’t.” (Bjarne Stroustrup)