From: Martin Steigerwald <Martin@lichtvoll.de>
To: linux-btrfs@vger.kernel.org, "kreijack@inwind.it" <kreijack@inwind.it>
Subject: Re: [RFC] New attempt to a better "btrfs fi df"
Date: Sat, 27 Oct 2012 18:43:40 +0200 [thread overview]
Message-ID: <201210271843.40540.Martin@lichtvoll.de> (raw)
In-Reply-To: <50899151.1070503@inwind.it>
Am Donnerstag, 25. Oktober 2012 schrieb Goffredo Baroncelli:
> Hi all,
>
> this is a new attempt to improve the output of the command "btrfs fi
> df".
>
> The previous attempt received a good reception. However there was no a
> general consensus about the wording.
>
> Moreover I still didn't understand how btrfs was using the disks.
> A my first attempt was to develop a new command which shows how the
> disks are divided in chunks. However it still was no clear. Then I
> realised that I need to merge the two output.
>
> Below the results. It shows how the disks is used by the different
> chunks.
>
> The code is pullable from
> http://cassiopea.homelinux.net/git/btrfs-progs-unstable.git
> branch
> info-cmd
>
> 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
Just a quick feedback:
I think this is rather long. And I find it more complicated than the older
output.
But maybe its more the vertically oriented formatting.
How about:
ghigo@emulato:~$ sudo ./btrfs fi df /mnt/btrfs1/
=== regular output ===
[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: 256.00KB of 921.75MB used
Data,Single: 0 of 8.00MB used
System,RAID1: 4 KB of 8.00MB used
System,Single: 0 of 4.00MB used
Metadata,RAID1: 24KB of 460.94MB used
Metadata,Single: 0 of 8.00MB used
^^^ possibly tabular ^^^
=== only with -d / --disks or -v? ===
/dev/vdb:
Data, RAID 0 307.25MB
Data,Single 8MB
System,Single 4MB
Metadata,RAID1 460.94MB
Metadata,Single 8MB
Unused 2,23GB
/dev/vdc:
Data,RAID 0 307,25MB
System,RAID1 8MB
Unused 2,69GB
/dev/vdd:
Data,RAID 0 307.25MB
System,RAID1 8MB
Metadata,RAID1 460.94MB
Unused 2.24GB
(one could include the usage in single disk view as well.)
Hmmm... but that also looks quite heavy.
Possibly this could be done tabular as well, like:
vdb vdc vdd
Data, RAID 0 307,25MB 307,25MB 307,25MB
…
System,RAID1 - 8MB 8MB
…
Unused 2,23GB 2,69GB 2,24GB
I like this. But what if the filesystem has 100 disks?
Hmmm, how about:
vdb vdc vdd
Data, RAID 0 307,25MB 307,25MB 307,25MB
vde vdf vdg
307,25MB 200MB 200MB
…
vdb vdc vdd
System,RAID1 - 8MB 8MB
…
vdb vdc vdd
Unused 2,23GB 2,69GB 2,24GB
vde vdf vdg
2,25GB 2,8GB 2,21GB
in such a case? Then each line has to have headings with devices. As long
as one line is enough, it only needs to be printed once at the beginning
of the table.
So in some form a tabular matrix of devices.
Other idea might be:
Allocated_area:
Data,RAID0: Size:921.75MB, Used:256.00KB
/dev/vdb: 307.25MB /dev/vdc: 307.25MB /dev/vdd: 307.25MB
And if same possibly:
Allocated_area:
Data,RAID0: Size:921.75MB, Used:256.00KB
/dev/vd[bcd]: 307.25MB
Hmmm, this is all playing with the same presentation.
Possibly one can at least hide empty trees. Or have them not created at
all at mkfs.btrfs time. There is no point in having / showing
Metadata,Single I think as long as it is not used.
Will think about this a bit.
Anyway I am fine with starting somewhere. Improvents can be made later on
also taking user feedback into account.
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-27 16:43 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 [this message]
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=201210271843.40540.Martin@lichtvoll.de \
--to=martin@lichtvoll.de \
--cc=kreijack@inwind.it \
--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 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.