Btrfs Heatmap - v5 ... snake, linear ... the virtual address space

Btrfs Heatmap - v5 ... snake, linear ... the virtual address space

[Hans van Kranenburg]

Hi,

I just tagged v5 of the Btrfs Heatmap utility, which visualizes the
usage of your btrfs filesystem:

https://github.com/knorrie/btrfs-heatmap

The main changes are:
 * [e464bfc] New --curve to select either hilbert, linear or snake
 * [b722ff4] New --sort to sort a full filesystem picture by either
dev_extents (--sort physical, default) or by chunk/stripes (--sort virtual)
 * Improved documentation, mainly about the curve alternatives [0] and
about the new virtual address space option [1], but also other small
improvements.
 * debian branch with packaging files

[0] https://github.com/knorrie/btrfs-heatmap/blob/master/doc/curves.md
[1] https://github.com/knorrie/btrfs-heatmap/blob/master/doc/sort.md

Since I got tired of cloning and updating the thing all over the place,
I added debian packaging. I'm planning to get all of it into Debian
unstable after the Stretch release.

For the impatient, use pbuilder or grab it from our repo at $dayjob:
http://packages.mendix.com/debian/pool/main/b/btrfs-heatmap/
http://packages.mendix.com/debian/pool/main/p/python-btrfs/

Have fun! And, share some of your results, if you have nice pictures or
create timelapses of filesystems behaving or misbehaving. :)

-- 
Hans van Kranenburg

Re: Btrfs Heatmap - v5 ... snake, linear ... the virtual address space

[Adam Borowski]

On Sun, Feb 19, 2017 at 01:01:29AM +0100, Hans van Kranenburg wrote:
> I just tagged v5 of the Btrfs Heatmap utility, which visualizes the
> usage of your btrfs filesystem

> Since I got tired of cloning and updating the thing all over the place,
> I added debian packaging. I'm planning to get all of it into Debian
> unstable after the Stretch release.

Why would you wait until after the release?  For packages not in testing,
unstable is fully open.  NEW processing is somewhat sluggish, but the hard
part, getting there, is full of bored people who can help.  Not sure if you
have a pet DD around -- if not, I for one can help with review/upload.

> For the impatient, use pbuilder or grab it from our repo at $dayjob:
> http://packages.mendix.com/debian/pool/main/b/btrfs-heatmap/
> http://packages.mendix.com/debian/pool/main/p/python-btrfs/

Here's a brief review:

There's a bunch of issues caught by automated tools.  You can run "lintian
-i *.changes", both on source and binary packages.  With -i, lintian gives
a helpful explanation how to fix problems it finds.

btrfs-headmap:
"Section" shouldn't be "python", it's merely written in python, not a
    library or a python-specific tool
man page should explain what the image says (colors, etc).

python-btrfs:
The python team wants to get rid of python2 as soon as possible.  As there's
no legacy code using this package, what's the point of providing python2
versions?


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: Btrfs Heatmap - v5 ... snake, linear ... the virtual address space

[Hans van Kranenburg]

On 02/19/2017 11:25 AM, Adam Borowski wrote:
> On Sun, Feb 19, 2017 at 01:01:29AM +0100, Hans van Kranenburg wrote:
>> I just tagged v5 of the Btrfs Heatmap utility, which visualizes the
>> usage of your btrfs filesystem
> 
>> Since I got tired of cloning and updating the thing all over the place,
>> I added debian packaging. I'm planning to get all of it into Debian
>> unstable after the Stretch release.
> 
> Why would you wait until after the release?  For packages not in testing,
> unstable is fully open.

Ah. I see.

> NEW processing is somewhat sluggish, but the hard
> part, getting there, is full of bored people who can help.  Not sure if you
> have a pet DD around -- if not, I for one can help with review/upload.

Nope. That would be great, I would really appreciate that.

>> For the impatient, use pbuilder or grab it from our repo at $dayjob:
>> http://packages.mendix.com/debian/pool/main/b/btrfs-heatmap/
>> http://packages.mendix.com/debian/pool/main/p/python-btrfs/
> 
> Here's a brief review:
> 
> There's a bunch of issues caught by automated tools.  You can run "lintian
> -i *.changes", both on source and binary packages.  With -i, lintian gives
> a helpful explanation how to fix problems it finds.

Ok.

> btrfs-headmap:
> "Section" shouldn't be "python", it's merely written in python, not a
>     library or a python-specific tool
> man page should explain what the image says (colors, etc).

Yeah, so have some more, the minimal parts of the online documentation,
in there.

> python-btrfs:
> The python team wants to get rid of python2 as soon as possible.

I see.

https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html

> As there's
> no legacy code using this package, what's the point of providing python2
> versions?

True. Probably I should just go python 3 only anyway. If so, better
sooner than later.

It was interesting to see how much effort it would take to support both,
but it already turned into an annoyance and extra work and fragility
now. For python-btrfs, it's the fs tree which I'm working on now where
things like filenames start causing the real headaches.

> Meow!

Moo!

-- 
Hans van Kranenburg