Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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

  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