From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f46.google.com ([74.125.83.46]:43579 "EHLO mail-ee0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750932Ab2J1K6x (ORCPT ); Sun, 28 Oct 2012 06:58:53 -0400 Received: by mail-ee0-f46.google.com with SMTP id b15so1651223eek.19 for ; Sun, 28 Oct 2012 03:58:52 -0700 (PDT) Message-ID: <508D1015.6050100@gmail.com> Date: Sun, 28 Oct 2012 11:59:33 +0100 From: Goffredo Baroncelli Reply-To: kreijack@inwind.it MIME-Version: 1.0 To: Martin Steigerwald CC: kreijack@inwind.it, Hugo Mills , linux-btrfs@vger.kernel.org, =?UTF-8?B?TWljaGFlbCBLasO2cmxpbmc=?= Subject: Re: [RFC] New attempt to a better "btrfs fi df" References: <50899151.1070503@inwind.it> <20121027223812.GB5042@carfax.org.uk> <508CF08D.8060203@gmail.com> (sfid-20121028_112200_553217_D070156D) <201210281138.02590.Martin@lichtvoll.de> In-Reply-To: <201210281138.02590.Martin@lichtvoll.de> Content-Type: text/plain; charset=UTF-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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