From: Goffredo Baroncelli <kreijack@gmail.com>
To: Martin Steigerwald <Martin@lichtvoll.de>
Cc: kreijack@inwind.it, "Hugo Mills" <hugo@carfax.org.uk>,
linux-btrfs@vger.kernel.org,
"Michael Kjörling" <michael@kjorling.se>
Subject: Re: [RFC] New attempt to a better "btrfs fi df"
Date: Sun, 28 Oct 2012 11:59:33 +0100 [thread overview]
Message-ID: <508D1015.6050100@gmail.com> (raw)
In-Reply-To: <201210281138.02590.Martin@lichtvoll.de>
On 2012-10-28 11:38, Martin Steigerwald wrote:
> Am Sonntag, 28. Oktober 2012 schrieb Goffredo Baroncelli:
>> On 2012-10-28 00:38, Hugo Mills wrote:
>>> On Sun, Oct 28, 2012 at 12:30:44AM +0200, Martin Steigerwald wrote:
>>>> Am Samstag, 27. Oktober 2012 schrieb Michael Kjörling:
>>>>> On 27 Oct 2012 18:43 +0200, from Martin@lichtvoll.de (Martin
>>>>
>>>> Steigerwald):
>>>>>> Possibly this could be done tabular as well, like:
>>>>> 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
>>>>
>>>> Hmmm, good idea. I like it this way around.
>>>>
>>>> It would scale better with the number of drives and there is a good
>>>> way to place the totals.
>>>>
>>>> I wonder about how to possibly include the used part of each tree.
>>>> With mostly 5 columns it might be doable.
>>>
>>>
>>> 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. :)
>>
>> I liked the Martin idea too. However I think that it is not applicable.
>> Even on my simple test bed I got
>>
>> Data,Single: 8.00MB
>> Data,RAID0: 307.25MB
>> Metadata,Single: 8.00MB
>> Metadata,RAID1: 460.94MB
>> System,Single: 4.00MB
>> System,RAID1: 8.00MB
>>
>> Plus we can have also Data+Metadata...
>
> One could still use multi row approach in that case:
>
> Data: RAID 0 System: RAID 1 Unused
> /dev/vdb 307.25 MB - 2.23 GB
> Data: RAID 1 System: RAID 0
> 250.12 MB 128 MB
> Data: RAID 0 System: RAID 1 Unused
> /dev/vdc 307.25 MB 8 MB 2.69 GB
> Data: RAID 1 System: RAID 0
> 250.12 MB -
> […]
>
> But still if if can be arbitrarily long due to that per object replication
> config, a vertical output might and leaving graphical representation to a
> Qt Quick application or so might be better.
Yes, this is my same feel: For console I prefer a text representation in
rows, leaving to a graphical GUI to show the information in columns..
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2012-10-28 10:58 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-25 19:21 [RFC] New attempt to a better "btrfs fi df" Goffredo Baroncelli
2012-10-25 19:40 ` cwillu
2012-10-25 19:59 ` Goffredo Baroncelli
2012-10-25 20:06 ` cwillu
2012-10-25 20:36 ` Chris Murphy
2012-10-25 20:49 ` cwillu
2012-10-25 20:52 ` Goffredo Baroncelli
2012-10-25 20:03 ` Chris Murphy
2012-10-25 20:11 ` cwillu
2012-10-25 20:41 ` Goffredo Baroncelli
2012-10-26 2:33 ` Chris Murphy
2012-10-26 3:36 ` cwillu
2012-10-26 4:03 ` Chris Murphy
2012-10-27 15:05 ` Chris Murphy
2012-10-27 16:43 ` Martin Steigerwald
2012-10-27 19:55 ` Michael Kjörling
2012-10-27 22:30 ` Martin Steigerwald
2012-10-27 22:38 ` Hugo Mills
2012-10-27 23:01 ` Michael Kjörling
2012-10-28 10:58 ` Martin Steigerwald
2012-10-28 8:45 ` Goffredo Baroncelli
2012-10-28 10:38 ` Martin Steigerwald
2012-10-28 10:59 ` Goffredo Baroncelli [this message]
2012-10-28 11:18 ` Michael Kjörling
2012-10-28 12:25 ` Goffredo Baroncelli
2012-10-28 12:48 ` Michael Kjörling
2012-10-28 13:22 ` Martin Steigerwald
2012-10-27 23:35 ` Chris Murphy
2012-10-28 11:20 ` Michael Kjörling
2012-10-28 9:01 ` Goffredo Baroncelli
2012-10-28 10:33 ` Martin Steigerwald
2012-10-28 10:58 ` Goffredo Baroncelli
2012-10-28 11:16 ` Martin Steigerwald
2012-10-28 18:27 ` Chris Murphy
2012-10-28 19:06 ` Michael Kjörling
2012-10-28 19:42 ` Chris Murphy
2012-10-28 20:09 ` Michael Kjörling
2012-10-28 20:19 ` Chris Murphy
2012-10-29 9:04 ` Michael Kjörling
2012-10-30 4:41 ` Chris Murphy
2012-10-28 19:42 ` Chris Murphy
2012-10-29 13:06 ` Randy Barlow
2012-10-29 22:21 ` [RFC][V2] " Goffredo Baroncelli
2012-10-30 9:42 ` Michael Kjörling
2012-10-30 18:15 ` Goffredo Baroncelli
2012-10-30 18:32 ` Michael Kjörling
2012-10-30 20:13 ` Chris Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=508D1015.6050100@gmail.com \
--to=kreijack@gmail.com \
--cc=Martin@lichtvoll.de \
--cc=hugo@carfax.org.uk \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=michael@kjorling.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox