Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: btdu, a sampling disk usage profiler for btrfs (github.com/cybershadow)
12 points by CyberShadow on Nov 8, 2020 | hide | past | favorite | 9 comments

This is great! I still have a feel for btrfs and think this tool's great explanations provide some good hints. I can also finally get a good and fast sense for a snapshot's size (I used to use to use btrfs send).

But ... is it normal to have massive amounts of data like everything except snapshots/ and var/ in my system subvolume being one of them, as error-nodes (/open (No such file or directory))?

Also: Is there a way to stop sampling after some time or amount of samples? It turns out your idea is correct and you don't actually need all that many to get a good impression :-)

Thanks for making it!

> as error-nodes (/open (No such file or directory))?

No... This particular one most likely indicates that the path on btdu's command line is not to the root subvolume. The attached explanation mentions this when the node is opened. If it's not this, then it's not something I'm aware of - what paths are under the node?

> Also: Is there a way to stop sampling after some time or amount of samples?

Once you're satisfied with the precision, you can press p to stop sampling. Does that do it or were you looking for a configurable limit?

Thanks for the feedback!

Thanks! A configurable limit would be nice, but p will do just fine.

My mistake was thinking that my mounted file system's root would be my btrfs's root, which of course it is not, it's itself a subvolume (a standard configuration has @system and @home, i think). When I re-ran btdu on the separately mounted root volume it worked flawlessly.

Maybe I'm the only one making this mistake, but maybe it makes sense to remind people of this. Especially since currently btdu doesn't fail with an error, but seems to try to navigate up to the root volume (it shows my @-subvolumes from wherever I start) but then presents a broken result.

Indeed, I will add a startup check in the next version.

Clever. I like it. I've given up trying to understand where my btrfs disk usage is, and I think this will help.

Written in D!

The basic idea behind this project is that you only need to cast 100 random samples to have roughly a 1% resolution, which is usually enough to know what ate your disk space. Even on very slow drives, resolving 100 samples should take no more than a few seconds.

Does it show the accuracy estimate, or it's wholly left to user guess?

It is displayed as "Resolution" on the bottom. (Total size divided by the number of samples so far.)

Good! The terminology was confusing for me, I am not used to the word "resolution" in this meaning and measured by KiB.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact