From: Goffredo Baroncelli <kreijack@inwind.it>
To: cwillu <cwillu@cwillu.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [RFC] New attempt to a better "btrfs fi df"
Date: Thu, 25 Oct 2012 21:59:36 +0200 [thread overview]
Message-ID: <50899A28.1050907@inwind.it> (raw)
In-Reply-To: <CAE5mzvgem05HN1QTFb6FkhHv0U=e1PTo7idPy06SR97cMbpFLg@mail.gmail.com>
On 2012-10-25 21:40, cwillu wrote:
>> I don't publish the patched because aren't in a good shape. However I
>> really like the output. The example is a filesystem based on three
>> disks of 3GB.
>>
>> It is clear that:
>> - - RAID0 uses all the disks
>> - - RAID1 uses two different disks
>>
>> Comments are welcome.
>>
>> Known bugs:
>> - - if a filesystem uses a disk but there is any chunk, the disk is not
>> shown (solvable)
>> - - this command need root capability (I use the BTRFS_IOC_TREE_SEARCH
>> to get the chunk info; so that is unavoidable)
>>
>>
>> ghigo@emulato:~$ sudo ./btrfs fi df /mnt/btrfs1/
>> [sudo] password for ghigo:
>> Path: /mnt/btrfs1
>> Summary:
>> Disk_size: 9.00GB
>> Disk_allocated: 1.83GB
>> Disk_unallocated: 7.17GB
>> Used: 284.00KB
>> Free_(Estimated): 6.76GB (Max: 8.54GB, min: 4.96GB)
>> Data_to_disk_ratio: 75 %
>>
>> Allocated_area:
>> Data,RAID0: Size:921.75MB, Used:256.00KB
>> /dev/vdc 307.25MB
>> /dev/vdb 307.25MB
>> /dev/vdd 307.25MB
>>
>> Data,Single: Size:8.00MB, Used:0.00
>> /dev/vdb 8.00MB
>>
>> System,RAID1: Size:8.00MB, Used:4.00KB
>> /dev/vdd 8.00MB
>> /dev/vdc 8.00MB
>>
>> System,Single: Size:4.00MB, Used:0.00
>> /dev/vdb 4.00MB
>>
>> Metadata,RAID1: Size:460.94MB, Used:24.00KB
>> /dev/vdb 460.94MB
>> /dev/vdd 460.94MB
>>
>> Metadata,Single: Size:8.00MB, Used:0.00
>> /dev/vdb 8.00MB
>>
>> Unused:
>> /dev/vdb 2.23GB
>> /dev/vdc 2.69GB
>> /dev/vdd 2.24GB
>
> Couple minor things, in order of personal opinion of severity:
>
> * Devices should be listed in a consistent order; device names are
> just too consistently similar
Could you elaborate ? I didn't understood well
>
> * System chunks shouldn't be listed between data and metadata; really,
> they're just noise 99% of the time anyway
Frankly speaking I don't know what contains. We can discuss a sorting or
an option to show/hide (depending by by the default)
>
> * I think it may be more useful to display each disk, with the
> profiles in use underneath. With a larger number of disks, that would
> make it _much_ easier to tell at-a-glance what is currently on a disk
> (that I may want to remove, or which I may suspect to be unreliable).
>
> * I'd rename "Unused" to "Unallocated" for consistency with the section title
Yes
> * (and I still detest the_underscores_between_all_the_words; it
> doesn't make parsing significantly easier, and it's an eyesore)
:-) we can work on that.
>
> * Three coats of blue paint plus a clear-coat is the One True Paint-Job.
> .
>
--
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-25 19: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 [this message]
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
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=50899A28.1050907@inwind.it \
--to=kreijack@inwind.it \
--cc=cwillu@cwillu.com \
--cc=linux-btrfs@vger.kernel.org \
/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