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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.