Hacker News new | past | comments | ask | show | jobs | submit login

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.

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