From: Martin Steigerwald <Martin@lichtvoll.de>
To: kreijack@inwind.it
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>,
cwillu <cwillu@cwillu.com>,
"Chris Murphy" <lists@colorremedies.com>,
"Hugo Mills" <hugo@carfax.org.uk>,
"Michael Kjörling" <michael@kjorling.se>
Subject: Re: [RFC] New attempt to a better "btrfs fi df"
Date: Sun, 28 Oct 2012 11:33:10 +0100 [thread overview]
Message-ID: <201210281133.10571.Martin@lichtvoll.de> (raw)
In-Reply-To: <508CF469.5070407@inwind.it>
Am Sonntag, 28. Oktober 2012 schrieb Goffredo Baroncelli:
> On 2012-10-25 21:21, Goffredo Baroncelli wrote:
> > Hi all,
> >
> > this is a new attempt to improve the output of the command "btrfs
> > fi df".
>
> Below you can see another iteration. I tried to address all the cwillu
> requests, which to me make sense.
>
> I thought a lot about chunk/disks vs disk/chunks, and I reached the
> conclusion that we could need both. In order to avoid a too long and
> redundant output, my idea is to have three different commands:
>
> 1) btrfs filesystem df <path> -> which show what it is called
> summary
> 2) btrfs filesystem disk-usage <path> -> which show what is called
> "Detail"
> 3) btrfs device disk-usage <path> -> which is like 2) but grouped
> by disk instead of chunks.
>
>
> This is an idea about which I want some comments. The example below
> show the latest results. I want to point out that I was not able to
> show the chunk usage per disk, because I don't have this information.
>
> The patches are not shaped to be showed, however the code is pullable
> from
>
> http://cassiopea.homelinux.net/git/btrfs-progs-unstable.git
> branch
> info-cmd (commit f90e55e7)
>
>
> $ sudo ./btrfs fi df /mnt/btrfs1/
> Path: /mnt/btrfs1
> Summary:
> Disk_size: 21.00GB
> Disk_allocated: 1.83GB
> Disk_unallocated: 19.17GB
> Used: 284.00KB
> Free_(Estimated): 15.76GB (Max: 20.54GB, min: 10.96GB)
> Data_to_disk_ratio: 75 %
Okay, so that btrfs fi df.
Which is a summary.
I think much more wouldn´t be a summary anymore, so thats okay.
And the following
> Allocated_area:
> Data,Single: Size:8.00MB, Used:0.00
> /dev/vdb 8.00MB
>
> Data,RAID0: Size:921.75MB, Used:256.00KB
> /dev/vdb 307.25MB
> /dev/vdc 307.25MB
> /dev/vdd 307.25MB
>
> Metadata,Single: Size:8.00MB, Used:0.00
> /dev/vdb 8.00MB
>
> Metadata,RAID1: Size:460.94MB, Used:24.00KB
> /dev/vdb 460.94MB
> /dev/vdd 460.94MB
>
> System,Single: Size:4.00MB, Used:0.00
> /dev/vdb 4.00MB
>
> System,RAID1: Size:8.00MB, Used:4.00KB
> /dev/vdc 8.00MB
> /dev/vdd 8.00MB
>
> Unallocated:
> /dev/vdb 2.23GB
> /dev/vdc 2.69GB
> /dev/vdd 2.24GB
> /dev/vdf 12.00GB
is detail shown by btrfs filesystem disk-usage?
While
> Disks:
> /dev/vdb 3.00GB
> Data,Single: 8.00MB
> Data,RAID0: 307.25MB
> Metadata,Single: 8.00MB
> Metadata,RAID1: 460.94MB
> System,Single: 4.00MB
> Unallocated: 2.23GB
>
> /dev/vdc 3.00GB
> Data,RAID0: 307.25MB
> System,RAID1: 8.00MB
> Unallocated: 2.69GB
>
> /dev/vdd 3.00GB
> Data,RAID0: 307.25MB
> Metadata,RAID1: 460.94MB
> System,RAID1: 8.00MB
> Unallocated: 2.24GB
>
> /dev/vdf 12.00GB
> Unallocated: 12.00GB
will be btrfs device disk-usage?
What was your reasoning for not using options to btrfs filesystem df? That
df doesn´t show more than "disk free" as well?
Then there is a little "inconsistency": "df" versus "disk-usage". I would
use either "disk-free" and "disk-usage" or "df" and "du". While regular
"du" is not disk-usage but a filesystem directory tree usage command.
I will think about this a bit more.
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
next prev parent reply other threads:[~2012-10-28 10:33 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
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 [this message]
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=201210281133.10571.Martin@lichtvoll.de \
--to=martin@lichtvoll.de \
--cc=cwillu@cwillu.com \
--cc=hugo@carfax.org.uk \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--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