Three plus one: disk usage meters

I keep ncdu installed as a matter of course. It’s one of those tools that I wish I could use more often, because what it does is very cool and very useful … just not very frequently.

I suppose disk usage meters in general suffer the same weak point — aside from perhaps a once-a-month file weeding, I don’t need them very often. The idea of a disk usage meter isn’t innovative either, seeing as you get du as a free gift in most distros. But what du lacks in presentation, others make up in style. ncdu was one example, and here’s another: gt5.

Depending on your personal preferences, you might like how gt5 tackles the issue — pushing its results into a text browser. After arranging directories by size, it creates an HTML file with internal links to pages that show directory size. You saw this this in the screenshot if you noticed that the page shown by elinks is a local address, and that the paging indicator runs up to 185. Go ahead, click again. 😯

In that way, you could take what gt5 outputs, and rearrange it for use in other ways. Open the same page in Firefox, and you get a similar result: a black page with color-coded links, file and directory sizes, and so forth. So gt5 creates something flexible and usable, beyond just showing you where the chunky files are.

(I should also mention that gt5 by default screens out some of the smallest files, which is why the directory arrangement in gt5 looks a little different from others.)

For a strictly tree-style view, tdu might be interesting to you.

Available from the same site as vtclock, tdu works in tandem with the aforementioned du command to build the tree you see there. You’ll need to pipe du through tdu, in order to get results: du /home/kmandla | tdu for starters.

tdu has a decent man page and a pair of help pages while it’s running too, so getting it to behave how you want shouldn’t take too long. For dependencies it needs almost nothing short of ncurses, and the results are more visual than the other two. Rather than just directory-by-directory lists of sizes and files, you move through the tree via keyboard, opening and closing the tree structure in much the same way as many other file access utilities.

If that appeals to you, you can probably better tune du and tdu to work together and get the results you prefer. Personally I find du‘s default file size value to be completely unhelpful, so the -h flag might be the first place to start. 😐

I don’t usually mention graphical tools any more, but it seems worthwhile to point out this one: fsv.


fsv is a little dated, what with the GTK1.2 interface and the rather old-school button images. In that sense, it won’t be as taxing on your hardware, even if it will require a little muscle to run. …

A little, in the sense that the 3D animation effects will ask more of your video card than any of the previous three. Clicking a directory shows a zooming effect, and expanding it via the right-click menu causes folders and files to stretch up like towers. Moving between directories on the left makes the view slide gracefully to its new point, a la Hollywood blockbuster special effects … sort of. 🙄

But after that, and aside from looking over the directories and files in your tree, fsv doesn’t do much. It has some basic file management abilities, but otherwise it’s nothing terrifically functional (I hate to use the word “gimmick” here, because it has some negative connotations. But really …).

So perhaps a talented coder will pick up fsv and give it a proper makeover (Edit: There is an fsv2, by the way), and add some fun(ction) to it. It seems like the basis for an interesting tool, but as it stands it’s just backdated and a bit thin. I suppose it would be useful in some sort of big-budget animatronic dinosaur movie though, if the production team decides not to pay for a Windows-based prop in their film. … :mrgreen:

P.S.: Images courtesy of Musca and Arch Linux. 😉

3 thoughts on “Three plus one: disk usage meters

    1. K.Mandla Post author

      That was the general idea. I’ve tried baobab and filelight in the past, but if I remember right, they were both tied rather closely to their desktop environments, and installing the dependent packages wasn’t really to my liking. 😐

  1. Sitaram

    filelight is not tied to KDE in the sense of requiring KDE to be *running*; I use it all the time under LXDE.

    It’s easily the best of the lot, though, IMO… although I can see the charm of a text mode one 🙂


Leave a Reply to Adam Williamson Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s