ZimaBoards, VisiData and disk space

• ~600 words • 2 minute read

A few months ago I bought a ZimaBoard to tinker around with. I'd down-sized greatly moving to New York last year and pretty much none of my tiny computers made the cut. I was in the market for a headless little something or another to stick under my bed, shell into once in a while, host tiny projects on and run some opinionated backup scripts.

My internal jury is still out on CasaOS, but I don't think it's bad for someone that isn't particularly hard-core about his homelab setup. It's basically just a Docker image and moderate system-management tool from a web-based GUI. There's an easily-accessible "app store" for quickly installing images/apps you might want.

  • If you have a link to the image on Docker Hub, it's pretty trivial to just fill out a form, specify the folders and ports you want things to map too and it'll automatically start any time you reboot the machine. I got Etherpad up and running quickly and it's not specifically listed or supported in their store.

  • It's running Debian Linux under the hood on an x86 architecture with built-in SSD and decent-enough RM (8GB RAM on my model) all of which made it interesting to me. It was also about the same (maybe cheaper?) than a comparable Raspberry Pi.

Somewhere along the way I lost a lot of disk space despite not installing that much. It came with 32GB of internal storage which struck me as plenty for someone who does not hoard a lot of media content. After a couple weeks though of installing and uninstalling numerous apps from their app store, I fill-up 29GB and could not figure out the who was hogging up the space. I removed all the apps and still didn't see it budge.

Piping stuff into VisiData is fun

So I decided to finally get to the bottom of things tonight. I logged into my machine remotely—thank you Cloudflare!—from the Recurse Center and used one of my favorite techniques: just piping random stuff into VisiData.

I logged into the machine, changed to the root (/) folder and ran:

du | vd

du measures disk space used by folder/files recursively from the place you call it. The default output is just two columns:

  1. The space the object is occupying
  2. The relative path to it from your current folder.

Visidata is very smart and will interpret all kinds of columnar and tabular data. Seriously, read the docs and check out the supported formats.

Then press Shift+# to tell VisiData the first column contains int values and then ] to sort things in descending order.

Ta-da! Now I can clearly see the culprits float to the top.

I'm sure/know there's a way to do all of those in a single command with du piping it in to sort and other command-line chicanery, but I like this way better.

For those wondering about what was actually eating up all the disk space, it turns out these were the primarily culprit

  • /var/log
  • /var/cache

I gave them a cursory glance to decide if I cared about anything in there, and after deciding I didn't I nuked them which cleaned-up about 10GB (!!) of files very quickly. I'm still not 100% certain how or why those got filled up so quickly, so I'm going to keep my eye on them in the future.