Where has my disk space gone? Flame graphs for file systems
brendangregg.com
brendangregg.com
My favorite tool for this is SpaceMonger v1.4.0 (http://www.aplusfreeware.com/categories/LFWV/SpaceMonger.htm...), which has a very neat layout algorithm. It's a Windows app but it works OK using Wine with only a few minor graphic glitches.
https://play.google.com/store/apps/details?id=com.google.and...
It's had most of the functionality ripped out, but it's been optimised to run blazingly fast.
Being unable to read thin spikes can be a good thing. There is only enough room to label the biggest boxes -- which are also the ones you care about the most.
If I were seriously building a GUI for this, it would let the user switch between visualizations to see which works best.
http://www.marzocca.net/linux/baobab/baobab-ringschart.html
The other has nested squares the size of each directory and its children. It sounds decent in theory, but is as bad as the "MyPlate" visualization in practice:
https://en.m.wikipedia.org/wiki/MyPlate
I'd put the flamegraph between these two in terms of usability.
[edit: Also, thanks for flamegraph, and documenting perf! I use your site all the time. It has saved countless hours at work!]
Starbursts do indeed use angles as part of the rendering algorithm, but for a given subdirectory, you end up comparing lengths just as you would in a flamegraph.
The key difference is that the screen real estate used to render the "icicles" increases linearly with the number of levels with sunbursts, but is constant for flamegraphs. This greatly reduces the "10 icicles, each 1-10 pixels wide" problem that flamegraphs have.
Also, jumping back to baobab, I find linking the directory tree view widget to the sunburst leads to a much more intuitive/obvious set of navigation primitives -- it makes it easy to jump to a parent or sibling of the current view.
As a side effect, they can (and do) put a bar graph on each entry in the tree view, which brings it to "2d position along common aligned scale" which is two levels better than flamegraph or sunburst (3 levels better than sunburst by your reading).
This doesn't help the tree view's usefulness for navigation, but it nicely complements the readability issues with sunbursts (or flamegraphs)
A flame graph box at different depths can be compared directly.
It's not something people really need to do though at any detail level. You don't compare sameish dirs to see which is slightly bigger, you check what the big consumers of space are.
――――――
Start it scanning then minimize it if you're not watching, rendering the screen slows the scan down. Just let it pain when finished.
After having tried both treemaps (windirstats, grand perspective, …) and sunbursts (daisy disk), I've got to say I much prefer the latter. It's not quite as space-efficient but it is much clearer and cleaner, and easier to drill down into.
Now while a flamegraph is equivalent to a sunburst in linear rather than circular shape, I don't think it's as good: the "outer rings" of the sunburst graph means more surface area for the same amount of data, which makes it much easier to evaluate the leaves's relative weight within their rings.
As for the specific tool, I use this one, similar principle: http://www.win.tue.nl/sequoiaview/
Not updated since 2002 but still works great on my Windows 10.
Perhaps it's just because I spend a lot of time looking at flame graphs, but this for me is perfect. It's just a shame that it requires two steps (run the script, open in browser). Perhaps I'll write a GUI wrapper around it that does everything all in one...
https://github.com/m1el/du-flamegraph
find $1 -type f | xargs -n32 -d'\n' -- du -ab \
| awk -F'\t' '{print $2" "$1;}' | sed 's#/##;s#/#;#g' \
| flamegraph.pl --title "Disk usage" --countname "bytes" \
--nametype "file" --width 1900 --minwidth 0.05
... and tested it using linux sources:http://m1el.github.io/du-flamegraph/linux-sources.svg
find $PWD -type f -ls | awk '{gsub("/", ";", $11); print $11" "$7}' | flamegraph.pl --title "Disk usage" --countname "bytes" --nametype "file" --width 1900 --minwidth 0.05Windows: WinDirStat
Alternative ways to download:
a) Use brew: brew install Caskroom/cask/disk-inventory-x
b) Another download link (same link used in brew/cask)[0]: http://www.derlien.com/diskinventoryx/downloads/dev/DIX1.0Un...
0: https://github.com/caskroom/homebrew-cask/blob/master/Casks/...
http://www.infoworld.com/article/3112358/microsoft-windows/w...
KFilelight only does sunburst I think, but I also have to say I like that, because it's easy to navigate (large click-able surface area).
[1] https://bitbucket.org/jeromerobert/k4dirstat/wiki/Home [2] https://community.linuxmint.com/img/screenshots/k4dirstat.pn...
(but maybe Filelight itself is available, since it uses Qt5 now)
In that article, the icicle graph (same as the flame graph) has long rectangles suitable for labeling -- although their example has the font rotated 90 degrees and not making the best use of that space.
But as you can see, these are all related. Hierarchy visualizations. If I were serious about building a tool to do disk space visualizations, I'd let the user toggle between all three visualizations.
I should also note that I think both treemaps and sunburst layout have their own cons, which I've mentioned here on HN.
http://antibody-software.com/web/software/software/wiztree-f...
> Since Wiztree works by scanning the MFT it's
> about an order of magnitude faster than [...]
> Treesize.
That's misleading - TreeSize also works by scanning the MFT.Which uses a circular visualization
I also really like the animation as you drill down into bloated folders - Really helps to bring attention to where you need to look in order to free up space. I can find offending files/folders much quicker in DaisyDisk that any other usage reporting tool.
DaisyDisk essentially shows the exact same info as FlameGraph — if you 'unwrap the wheel' it's exactly the same! — but the latter makes the excellent design decision to label many of the bigger directories on the graph, rather than just a single level in a key. Often, when you're looking for big directories, you're really looking for big unnecessary directories, and being able to see way ahead really helps.
It's probably the first OS X App where I bought licenses for the whole family; they all benefited from it.
Mainly in terms of ratios - I think my mind perceives size ratios better on a circular pie style presentation (as DaisyDisk does), rather than stacked blocks as most other utilities use.
I'm a die-hard fan of `du -kx dir | sort -rn | less`.
That's all the files and subdirectories, and multiple levels of subdirectories, shown _at the same time_. Without needing to navigate in and out of directories.
If there's a way to do this using ncdu, then I've failed to find it. Screenshot please.
--- /mnt/src/6/linux-4.9-rc5 ---------------------
401.7 MiB [##########] /drivers
135.6 MiB [### ] /arch
37.3 MiB [ ] /fs
35.3 MiB [ ] /include
34.4 MiB [ ] /Documentation
32.2 MiB [ ] /sound
27.6 MiB [ ] /net
13.4 MiB [ ] /tools
7.5 MiB [ ] /kernel
5.9 MiB [ ] /firmware
3.6 MiB [ ] /lib
3.4 MiB [ ] /scripts
3.3 MiB [ ] /mm
3.2 MiB [ ] /crypto
2.3 MiB [ ] /security
1.1 MiB [ ] /block
880.0 KiB [ ] /samples
424.0 KiB [ ] /virt
[...]
I don't see subdirectories.Linux source is here: https://www.kernel.org/
Take that ncdu output above: "/drivers" is visible in the flame graph, whereas "/virt" is not. It's only printing the names of the largest rectangles -- the ones you care about, helping draw your attention to where it should be drawn.
Screenshot: http://www.steffengerlach.de/freeware/scnshot.gif
In the example, the 3.88% used by the tower of "linux-4.9-rc5/drivers/gpu/drm/amd/include" looks larger than "linux-4.9-rc5/net" over on the right just because the tree is deeper. Similarly, on my Windows machine at work, "C:\Users\LeifCarrotson\AppData\Local\Microsoft\Outlook\Leif@Carrotson.com.pst" (where my email is stored) would take up more screen space than "C:\hiberfil.sys", just because it's taller.
I don't much care about the depth of the filesystem. The various tree views seem more useful.
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bu...
This flat representation is probably better because it doesn't exaggerate the size of deeply nested files, but I find the example in the article a bit harder to read.
[1]: https://daisydiskapp.com/ [2]: http://www.jgoodies.com/freeware/jdiskreport/
> The sunburst layout is equivalent to the icicle layout as used by flame graphs, but it uses polar coordinates.7 While this can generate interesting shapes, there are some difficulties: function names are harder to draw and read from sunburst slices than they are in the rectangular flame-graph boxes. Also, comparing two functions becomes a matter of comparing two angles rather than two line lengths, which has been evaluated as a more difficult perceptual task.10
(I should have mentioned that they visually exaggerate deeper slices, too). I think they are pretty, but, more difficult to read.
The other app has a pie chart and trees. Both can't visually show everything at once, all subdirectories.
Shows you a radial chart of your disk you can explore and zoom into and even better lets you delete directly from its ui.
e.g.
SELECT sum(bytes) FROM files
GROUP BY extension
ORDER BY sum(bytes) DESC;
You can GROUP BY any file attributesAt the other end of the practicality scale was the SGI tool fsn, recreated in open source by this: https://en.m.wikipedia.org/wiki/File_System_Visualizer
Quite ridiculous, it's not like this hasn't been something Unix has been doing since almost the beginning!
Right now we have a ridiculous situation where the winsxs folder gets out of sync with the c:\windows\system32 folder. Nothing treeview or any other utility can you daily do about it either. And until recently that winsxs store was holding gigabytes of old and useless updates, because Microsoft's updates never removes these components (recently - last year some time I think- they updated the disk cleanup GUI to delete this stuff from Windows 7 upwards. IMO they recognised a big stuff up caused by their product management team's decision, which in turn caused this unheralded enhancement).
I usually use Disk Inventory X but I'd really like to correlate usage increases to specific dates / app installs, so it'd be nice to see stats over time, e.g:
- Installed Android Studio on Feb 1st: Usage in /Applications increased by 850MB, usage in User folder increased by 10G (450MB for android-studio-2.x.dmg, 8.4GB in /Users/name/.android, largest leaf in /Users/name/.android/sdk etc)
I tried to do this with the 'du' tools once but simply writing the current output to disk would take ages and diffs would need some heavy lifting to make sense of.
For disk usage I would normally use du and/or filelight which is also great.
This is a nice way to visualise all the sub directories too in one go though.
On a side note, when I'm on a server with disk space problems, I usually debug it like this:
# cd /
# du -sm | sort -n | tail
(lists the biggest space users)
# cd <unusually big subdir>
(goto step 2: du -sm...)
Works like charm, but can be a bit slow when applied to large and slow disks.On Android I use DiskUsage: https://play.google.com/store/apps/details?id=com.google.and...
Screenshot: http://imgur.com/CrVcdEk
qcachegrind renders profiling output as tree maps, and for filesystems there are many alternatives, e.g: Baobab (aka Disk usage analyzer) does this, also KDirStat.
I get a menu with options for not-installed apps - filelight, kdiskfree and two partition tools. 'sudo apt install filelight' and it works, but TBH I'm not keen on filelight, would be nice to have k4dirstat as an option there (sounds like a bug report is due).
cd / && du -sh *Output is related to your present working directory.
du's output does the first level of directories, but not subdirectories, and also requires reading of text rather than visually comparing line lengths (easier).
Or, it may not (the initial problem I had, I already knew the high level breakdowns, and was hunting for wasted 1%'s here and there -- the flame graph made it easy to spy everything at once).
Another use of the flame graph approach is with automated build software. Imagine automatically generating one with every linux version, to keep track of where growth is.
Human-readable units are nice, but without them it's easier to sort by size.
du -s * | sort -n du -sh * | sort -h coreutils-5.93.tar.bz2 2005-11-06 09:06 du -h | perl -e 'sub h{%h=(K=>10,M=>20,G=>30);($n,$u)=shift=~/([0-9.]+)(\D)/; return $n*2**$h{$u}}print sort{h($b)<=>h($a)}<>;'
Source: http://serverfault.com/a/62422/76878