All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>, linux-btrfs@vger.kernel.org
Subject: Re: Btrfs Heatmap - v2 - block group internals!
Date: Thu, 17 Nov 2016 19:51:17 +0100	[thread overview]
Message-ID: <68eecdb7-90e4-a5ba-ca63-f714faf88ede@mendix.com> (raw)
In-Reply-To: <fda30533-068c-69d8-064f-fbbec06a6d22@cn.fujitsu.com>

Hey,

On 11/17/2016 02:27 AM, Qu Wenruo wrote:
> 
> At 11/17/2016 04:30 AM, Hans van Kranenburg wrote:
>> In the last two days I've added the --blockgroup option to btrfs heatmap
>> to let it create pictures of block group internals.
>>
>> Examples and more instructions are to be found in the README at:
>> https://github.com/knorrie/btrfs-heatmap/blob/master/README.md
>>
>> To use the new functionality it needs a fairly recent python-btrfs for
>> the 'skinny' METADATA_ITEM_KEY to be present. Latest python-btrfs
>> release is v0.3, created yesterday.
>>
> Wow, really cool!

Thanks!

> I always dream about a visualizing tool to represent the chunk and
> extent level of btrfs.
> 
> This should really save me from reading the boring dec numbers from
> btrfs-debug-tree.
> 
> Although IMHO the full fs output is mixing extent and chunk level
> together, which makes it a little hard to represent multi-device case,
> it's still an awesome tool!

The picture of a full filesystem just appends all devices together into
one big space, and then walks the dev_extent tree and associated
chunk/blockgroup items for the %used/greyscale value.

I don't see what displaying a blockgroup-level aggregate usage number
has to do with multi-device, except that the same %usage will appear
another time when using RAID1*.

When generating a picture of a file system with multiple devices,
boundaries between the separate devices are not visible now.

If someone has a brilliant idea about how to do this without throwing
out actual usage data...

-- 
Hans van Kranenburg

  reply	other threads:[~2016-11-17 18:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-12 23:19 Btrfs Heatmap - visualize your filesystem Hans van Kranenburg
2016-11-16 20:30 ` Btrfs Heatmap - v2 - block group internals! Hans van Kranenburg
2016-11-17  1:27   ` Qu Wenruo
2016-11-17 18:51     ` Hans van Kranenburg [this message]
2016-11-17 19:27       ` Austin S. Hemmelgarn
2016-11-17 21:08         ` Hans van Kranenburg
2016-11-18 12:36           ` Austin S. Hemmelgarn
2016-11-18 14:37             ` Hans van Kranenburg
2016-11-18 15:33               ` Austin S. Hemmelgarn
2016-11-18  2:08         ` Qu Wenruo
2016-11-18 15:08           ` Hans van Kranenburg
2016-11-18 15:30             ` Austin S. Hemmelgarn
2016-11-18 16:18               ` Hans van Kranenburg
2016-11-19  0:57             ` Qu Wenruo
2016-11-19  1:38               ` Hans van Kranenburg

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=68eecdb7-90e4-a5ba-ca63-f714faf88ede@mendix.com \
    --to=hans.van.kranenburg@mendix.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@cn.fujitsu.com \
    /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.