Linux commando: du

1. De basis

du loopt een mappenboom door en telt op hoeveel ruimte de bestanden erin innemen. Die zin bevat drie aannames die het uit elkaar halen waard zijn, want bij elk ervan gaat het mis.

1.1 De eenvoudigst mogelijke toepassing

Twee opties doen negentig procent van het werk, en je wilt ze bijna altijd allebei:

$ du -sh /var/log
1.4G    /var/log

Zonder -s krijg je een regel voor elke onderliggende map, en op een grote boom zijn dat duizenden regels die voorbijscrollen. Zonder -h krijg je een getal in blokken van 1024 bytes, en dat wil niemand uit het hoofd delen.

De nuttigste aanroep uit dit hele artikel is deze, en die is het onthouden waard:

$ du -h -d 1 /var | sort -h -r
8.2G    /var
6.1G    /var/lib
1.4G    /var/log
403M    /var/cache
...

-d 1 beperkt de uitvoer tot een niveau lager, en sort -h -r zet de grootste bovenaan. Draai dat, stap de grootste map in, draai het opnieuw. Drie of vier rondes en je hebt gevonden wat de schijf opat.

1.2 du telt blokken, geen bytes

Hier is de eerste aanname om los te laten. du meldt niet hoeveel bytes er in je bestanden zitten. Het meldt hoeveel ruimte het bestandssysteem toewees om ze te bewaren, en dat zijn verschillende getallen.

$ echo -n "x" > tiny.txt          # a one-byte file

$ du --apparent-size -b tiny.txt
1       tiny.txt                  # one byte of content

$ du tiny.txt
4       tiny.txt                  # four KILOBYTES on disk

$ stat -c '%s bytes, %b blocks of %B' tiny.txt
1 bytes, 8 blocks of 512

Een bestandssysteem deelt ruimte uit in blokken, doorgaans 4096 bytes op ext4. Een bestand van een byte krijgt een heel blok, en 4095 bytes daarvan zijn verspild. Dat is geen fout, zo werkt blokindeling nu eenmaal, en het betekent dat een map met veel kleine bestanden veel meer kost dan de som van hun inhoud. Paragraaf 7.4 zet er getallen bij.

Nieuwere bestandssystemen maken dit in twee richtingen ingewikkelder. Extents, inline opslag voor heel kleine bestanden en tail packing kunnen alles strakker inpakken dan het platte blokmodel suggereert, terwijl compressie de toegewezen omvang kleiner kan maken dan de inhoud. De 4 kB-regel is een goed uitgangsmodel voor ext4 en een vertrekpunt elders, geen wet.

Nog een ding is een object met een eigen omvang: de map zelf. Die moet de namen bewaren die erin staan, dus hij kost ruimte zelfs als hij leeg is, en hij groeit terwijl je hem vult:

$ mkdir emptydir
$ du -h emptydir
4.0K    emptydir                  # empty, and already 4 KB

$ du -h --apparent-size emptydir
0       emptydir                  # no content at all

$ for i in $(seq 1 3000); do : > emptydir/file-with-a-longish-name-$i; done
$ stat -c '%s bytes' emptydir
167936                            # the directory itself is now 164 KB of names

du telt dus geen bestandsinhoud op. Het telt toegewezen ruimte op over elk object dat het langsloopt, mappen inbegrepen, en dat is nog een kleine reden dat het totaal niet gelijk is aan een som van bestandsgroottes.

1.3 du en df beantwoorden verschillende vragen

Dit is het onderscheid waar het hele artikel om draait. Zeg het een keer hardop en een hoop verwarring verdwijnt:

Het snelheidsverschil is niet subtiel, en het volgt rechtstreeks uit de methode:

$ du -sxh /usr/share       0.68 s        # 207,983 files, every one stat'ed
$ df -h /                  0.00 s        # one question to the filesystem

Het juiste mentale model: df vraagt het bestandssysteem hoeveel ruimte er over is. du vraagt de bestanden hoeveel ruimte zij innemen. Als die twee het oneens zijn, bestaat het verschil uit dingen die du niet kan zien, en paragraaf 7.1 is een opsomming daarvan.

3. Een korte geschiedenis

Beide commando's zijn zo oud als Unix zelf. Niet "vroeg Unix": de allereerste uitgave.

De GNU-versies noemen hun auteurs, en de overlap tussen de twee lijsten is geen toeval:

$ man du | grep -A2 AUTHOR
       Written by Torbjorn Granlund, David MacKenzie, Paul Eggert, and
       Jim Meyering.

$ man df | grep -A2 AUTHOR
       Written by Torbjorn Granlund, David MacKenzie, and Paul Eggert.

Een historisch detail duikt nog dagelijks op. De standaardeenheid is 1024 bytes, maar POSIX schrijft 512 voor, dus hetzelfde commando geeft je in een POSIX-strikte omgeving twee keer zo grote getallen:

$ du tiny.txt
4       tiny.txt

$ POSIXLY_CORRECT=1 du tiny.txt
8       tiny.txt                  # same file, 512-byte blocks

En POSIXLY_CORRECT is niet de enige variabele die meespeelt. Drie andere veranderen de eenheid ook, en du volgt degene die hij het eerst tegenkomt:

$ du -s target
20484   target                    # the default, 1024-byte blocks

$ DU_BLOCK_SIZE=1M du -s target
21      target
$ BLOCK_SIZE=1M du -s target
21      target
$ BLOCKSIZE=1M du -s target
21      target
$ POSIXLY_CORRECT=1 du -s target
40968   target                    # 512-byte blocks: twice the number

Een kaal getal van du hangt dus af van vier omgevingsvariabelen, die elk gezet kunnen zijn in een cron-omgeving, een CI-runner of iemands .bashrc. Daarom is -h, -k of -B in een script niet optioneel. Aan het getal hangt geen eenheid, en de eenheid wordt bepaald door een omgeving die je misschien niet beheert.

De andere overdraagbaarheidsvraag is welke opties er uberhaupt zijn. Het meeste van wat GNU du prettig maakt is een GNU-uitbreiding, en in een minimale container-image krijg je BusyBox. Getest tegen BusyBox 1.38:

De -b-regel verdient een moment, want de twee schrijfwijzen zijn niet uitwisselbaar qua eenheid. Op een sparse bestand van 50 MB drukt du --apparent-size 51200 af (in blokken van 1 kB) terwijl du -b 52428800 afdrukt (bytes). GNU definieert -b als --apparent-size --block-size=1, en BusyBox doet hetzelfde, dus -b is de overdraagbare keuze zolang je bytes verwacht.

Let ook op de diepteregels, want die tellen voor wat je dagelijks typt. -d 1 werkt overal; --max-depth=1 niet. Ze doen precies hetzelfde, dus er is geen reden om de lange te leren. Daarom gebruikt elk voorbeeld in dit artikel -d.

$ docker run --rm busybox du --max-depth=1 /t
du: unrecognized option '--max-depth=1'

$ docker run --rm busybox du -d 1 /t
ok

macOS en de BSD's zijn weer een derde dialect, met hun eigen schrijfwijze voor een deel hiervan. Houd het op alles wat mogelijk geen GNU is bij -s, -h, -k, -x, -a en -d, en raadpleeg de lokale handleidingpagina voor de rest.

5. Gemiddelde toepassingen

5.1 Dingen uitsluiten

--exclude neemt een patroon en slaat alles over wat erop past. Dat telt zwaarder dan het klinkt, want op een echte server is het interessante getal meestal "hoe groot is dit als ik de delen negeer die ik al ken":

$ du -sh /var/www/site --exclude='*/cache'
$ du -sh /home/peter --exclude='.cache' --exclude='.local/share/Trash'
$ du -sh /srv/project --exclude='node_modules' --exclude='.git'

Bij meer dan twee of drie patronen zet je ze in een bestand en gebruik je -X:

$ cat skip.txt
node_modules
.git
*.iso

$ du -sh -X skip.txt /srv/project

5.2 Drempels

-t (afkorting van threshold) verbergt alles onder een bepaalde omvang, en dat maakt van een muur uitvoer een korte lijst:

$ du -h -d 3 -t 1G /var          # only things over a gigabyte
$ du -ah -t 100M /home/peter     # only files over 100 MB

Een negatieve drempel keert het om, en dat is de minder voor de hand liggende helft en af en toe precies goed:

$ du -ah -t -1k /srv/data        # only entries SMALLER than 1K

Zo vind je de map met honderdduizend piepkleine bestanden, en paragraaf 7.4 legt uit dat dat een echt probleem is en niet alleen slordigheid.

5.3 Diepte zonder optelling: -S

-S (afkorting van separate-dirs) rapporteert de eigen inhoud van elke map zonder de submappen erbij op te tellen. Vergelijk met de standaard:

$ du -h sub                     $ du -Sh sub
2.1M    sub/a/b/c               2.1M    sub/a/b/c
4.1M    sub/a/b                 2.1M    sub/a/b
6.1M    sub/a                   2.1M    sub/a
8.1M    sub                     2.1M    sub

De linkerkolom telt op; de rechter niet. Gebruik -S als je wilt weten welke enkele map de bestanden bevat, en niet welke tak van de boom het zwaarst is. Dat zijn verschillende vragen en mensen kiezen vaak de verkeerde.

5.4 Bestanden tellen in plaats van bytes

Een bestandssysteem kan aan twee dingen tekortkomen: ruimte, en inodes. Raakt het door zijn inodes heen, dan krijg je "No space left on device" terwijl df -h vrolijk meldt dat er genoeg vrij is. --inodes vindt de boosdoener met dezelfde wandeling:

$ du -sh many
12K     many                     # 500 empty files: almost no space

$ du -s --inodes many
501     many                     # but 501 inodes

$ du --inodes -d 1 /var | sort -n -r | head

Controleer of dat je probleem is voordat je op jacht gaat naar grote bestanden:

$ df -i /                        # -i for inodes
Filesystem       Inodes  IUsed  IFree IUse% Mounted on
/dev/mapper/...    120M    14M   106M   12% /

Mailwachtrijen, sessiemappen en caches met kleine bestanden zijn de gebruikelijke verdachten. Honderdduizend bestanden van een byte gebruiken vrijwel geen ruimte en honderdduizend inodes.

5.5 Het recept

Bij elkaar is dit de volgorde voor "de schijf zit vol en ik weet niet waarom":

$ df -h                          # 1. which filesystem, and is it really full?
$ df -i                          # 2. or has it run out of inodes instead?
$ du -shx /* 2>/dev/null | sort -h -r | head       # 3. top level
$ du -h -d 1 -x /var | sort -h -r | head           # 4. descend into the winner
$ du -h -d 1 -x /var/lib | sort -h -r | head       # 5. and again
$ du -ah -t 100M /var/lib/docker | sort -h -r      # 6. finally, the files

Stap 1 en 2 kosten een seconde en sluiten de twee problemen uit die van een afstand identiek lijken. Stap 3 tot 6 zijn hetzelfde commando met telkens een ander pad. Paragraaf 6.1 legt de -x uit.

7. Iets wat de meeste gebruikers niet weten

7.1 Waarom df en du het oneens zijn

Dit is de vraag die mensen naar dit commando brengt, en het antwoord is niet een ding. Het zijn er vijf, ze stapelen op, en de laatste geldt alleen voor sommige bestandssystemen.

Gereserveerde blokken. Begin met df die het met zichzelf oneens is. Op deze machine tellen zijn eigen drie kolommen niet op:

$ df --block-size=1 /
size  = 2011859927040
used  = 1808341385216
avail =  101246103552
used + avail = 1909587488768
missing      =  102272438272 bytes, which is 5.1% of size

Ongeveer vijf procent van een ext4-bestandssysteem is standaard gereserveerd voor root. Het is geen vrije ruimte wat jou betreft, en het wordt door geen enkel bestand gebruikt, dus het hoort in geen van beide kolommen. Daarom kan een schijf "100% vol" melden terwijl er technisch nog enkele gigabytes zijn. Je kunt het terugnemen op een datavolume, waar niets die veiligheidsmarge nodig heeft:

$ sudo tune2fs -m 1 /dev/sdb1     # reduce the reserve from 5% to 1%

Doe dat niet op het rootbestandssysteem. De reserve bestaat zodat een volle schijf root niet belet in te loggen en syslog niet belet te schrijven, en dat is precies wanneer je beide nodig hebt.

Verwijderde bestanden die nog openstaan. Dit is de grote, en het is de reden voor de meeste spectaculaire verschillen. Een bestand ontkoppelen haalt de naam weg; de ruimte komt pas terug als het laatste proces dat het open heeft loslaat:

$ dd if=/dev/zero of=ghost.bin bs=1M count=300
$ exec 9< ghost.bin               # hold it open
$ rm ghost.bin                    # the name is gone

$ du -sh .
11M     .                          # du sees nothing: there is no name to walk

df used before rm  : 1724868 MB
df used after  rm  : 1724868 MB   # df has not moved
df after closing   : 1724568 MB   # 300 MB back, at once

Een logbestand dat verwijderd wordt terwijl de applicatie het nog open heeft is de klassieke versie. De schijf blijft vol tot je de dienst herstart, en geen enkele du laat je dat bestand zien. Zo vind je ze:

$ sudo lsof -nP +L1               # +L1: link count below 1, meaning deleted
$ sudo lsof -nP | grep deleted

De oplossing is het proces herstarten dat de descriptor vasthoudt, of via /proc afkappen als dat niet kan: : > /proc/PID/fd/N.

Bestanden verborgen onder een koppelpunt. Zaten er bestanden in een map voordat er iets overheen gekoppeld werd, dan bestaan die nog steeds en nemen ze nog steeds ruimte in. Ze zijn alleen onbereikbaar, dus du kan ze niet tellen:

$ sudo mkdir /mnt/tmp-check
$ sudo mount --bind / /mnt/tmp-check     # see the real root, unobscured
$ sudo du -shx /mnt/tmp-check/var        # count what is actually there
$ sudo umount /mnt/tmp-check

Deze treft mensen die een map vulden voordat ze er een schijf op koppelden, en dat is makkelijk te doen tijdens een installatie en daarna onzichtbaar.

Overhead van het bestandssysteem. Inodetabellen, journalen en metagegevens nemen ruimte in die bij geen enkel bestand hoort. Op een groot bestandssysteem zijn dat gigabytes, en het verklaart een blijvend klein gat in plaats van een plotseling gat.

En op een modern bestandssysteem: de boekhouding zelf. Alles hierboven gaat uit van ext4, waar een blok bij precies een bestand hoort. Btrfs, ZFS en XFS breken die aanname op manieren die de vraag moeilijker maken in plaats van het antwoord fout:

Deze machine draait ext4, waar die dingen niet spelen: cp --reflink=always faalt hier met "Operation not supported". Maar op Btrfs of ZFS zijn ze doorgaans de voornaamste oorzaak van een gat tussen df en du, en geen enkel gereedschap dat paden afloopt kan ze verantwoorden. Gebruik dan het gereedschap van het bestandssysteem zelf: btrfs filesystem usage, btrfs qgroup show, of zfs list -o space.

Bij elkaar: df telt alles wat het bestandssysteem heeft vastgelegd. du telt wat het kan bereiken door namen af te lopen. Het gat is gereserveerde ruimte, plus bestanden zonder naam, plus bestanden zonder pad, plus de eigen boekhouding van het bestandssysteem, plus wat jouw bestandssysteem achter de schermen deelt of comprimeert.

7.2 Standaardfout weggooien laat du liegen

Iedereen schrijft 2>/dev/null om de rechtenwaarschuwingen het zwijgen op te leggen. Kijk wat dat met het antwoord doet:

$ du -sh /root 2>/dev/null
4.0K    /root                     # looks like an empty directory

$ du -sh /root
du: cannot read directory '/root': Permission denied
4.0K    /root                     # same number, now with a warning

Die 4.0K is de mapregel zelf. /root bevat op deze machine een map Desktop en een map snap, en geen van beide zit in het totaal. Het getal is geen fout, het is een eerlijk verslag van wat du kon zien, en het deel dat je vertelde dat hij niet alles kon zien ging naar standaardfout.

Dus als je du -shx /* 2>/dev/null als gewone gebruiker draait, behandel elk getal dan als een ondergrens. Draai het met sudo als het antwoord ertoe doet, en lees de waarschuwingen als dat niet zo is.

7.3 du telt overlappende argumenten niet dubbel

Geef du twee paden waarvan het ene het andere bevat, en hij is slimmer dan je zou denken:

$ du -sh sub/a
6.1M    sub/a

$ du -sh sub/a/b
4.1M    sub/a/b

$ du -sh sub/a sub/a/b -c
6.1M    sub/a
6.1M    total                     # not 10.2M

Hij houdt bij wat hij binnen een enkele run al bezocht heeft en weigert dezelfde blokken twee keer op te tellen. Dat maakt du -shc /home/* betrouwbaar, en het is hetzelfde mechanisme dat hard links in paragraaf 6.3 afhandelt.

De beperking is er ook dezelfde: dit geldt alleen binnen een aanroep. Twee losse du-commando's weten niets van elkaar.

7.4 Kleine bestanden kosten meer dan ze wegen

Paragraaf 1.2 liet een bestand van een byte zien dat 4 kB gebruikt. Vermenigvuldig dat met een echte map en het houdt op een curiositeit te zijn:

100,000 files of 100 bytes each

apparent size:  100,000 x 100    =  10 MB
device usage:   100,000 x 4096   = 410 MB

Veertig keer groter. Een mailspool, een map met PHP-sessies, een cache met miniaturen of een Git-objectopslag kan een orde van grootte meer ruimte innemen dan de data erin, en du --apparent-size naast een kale du vertelt je meteen of dat is waar je naar kijkt:

$ du -sh /var/lib/php/sessions
$ du -sh --apparent-size /var/lib/php/sessions
# a big gap between these two means "many small files", not "much data"

En denk aan paragraaf 5.4: diezelfde map verbruikt ook een inode per bestand, en dat is een voorraad die je los kunt uitputten.

7.5 du is traag omdat het niet anders kan

Er is geen sluiproute. Om een map op te tellen moet du elk bestand erin stat-en, want geen enkel gangbaar bestandssysteem houdt een lopend totaal per map bij. Daarom schaalt de kosten met het aantal bestanden en niet met hun omvang:

$ find /usr/share -xdev | wc -l
207983

$ du -sxh /usr/share       0.68 s     (cold)
$ du -sxh /usr/share       0.28 s     (warm, from the kernel's cache)
$ df -h /                  0.00 s

Twee praktische gevolgen. du draaien op een grote boom warmt de cache op, dus een tweede run is veel sneller en elke meting na de eerste is te optimistisch. En op een drukke productieserver is een volledige du / niet gratis: het verdringt nuttige gegevens uit de cache en veroorzaakt veel metadata-I/O. Kies -x, kies een smal beginpunt, en overweeg ionice -c3 als het onder werktijd moet.

7.6 Weten waar du ophoudt

ncdu verdient de bovenste regel en is het overal installeren waard. Het doet dezelfde wandeling als du, een keer, en geeft je daarna een interactieve boom waarin je kunt bewegen en verwijderen, waarmee de afdaling in vier rondes uit paragraaf 5.5 pijltjestoetsen wordt.

9. Veelgemaakte fouten

9.1 Mythe versus werkelijkheid

9.2 Andere valkuilen om te vermijden

• du / zonder -x draaien op een bureaublad. Hij daalt af in /run/user/1000/gvfs en wat dat ook koppelt, en komt misschien nooit terug.
• Uitvoer van du lezen zonder te sorteren. De volgorde is die van de mapwandeling, niet die van de omvang. sort -h -r is niet optioneel.
• -h vergeten aan een kant van een pipe. sort -h heeft de achtervoegsels nodig die du -h produceert. du -k | sort -n werkt ook; de twee mengen niet.
• awk '{print $1}' gebruiken om de omvang eruit te halen. Werkt tot een pad een spatie bevat. Het scheidingsteken is een tab, dus cut -f1 is juist.
• Verwijderen vanuit ncdu zonder te kijken. Het verwijdert direct en definitief, zonder prullenbak en zonder ongedaan maken.
• -L gebruiken zonder na te denken over waar de links heen gaan. Een symlink kan buiten de boom wijzen, naar een ander bestandssysteem, of terug naar een bovenliggende map. -L volgt ze allemaal, dus een scan waarvan je een seconde verwachtte kan ver afdwalen.
• du de schuld geven op een Btrfs- of ZFS-server. Bestaan er snapshots, dan zit de ontbrekende ruimte daarin en vindt geen enkel gereedschap dat paden afloopt die. btrfs filesystem usage of zfs list -o space beantwoorden de vraag die du structureel niet kan.
• Aannemen dat du op een netwerkschijf snel is. Elke stat is een ronde over het netwerk. Een boom die lokaal twee seconden kost kan over NFS of SMB twintig minuten duren.
• Totalen van du uit twee aparte runs vergelijken. Hard links worden alleen binnen een run ontdubbeld, dus twee runs over bomen die bestanden delen tellen ertussen dubbel.
• Een totaal vertrouwen dat genomen is terwijl er geschreven wordt. du is niet atomair. Op een actieve server is het getal een uitsmering over de tijd die de wandeling kostte.
• Ruimte vrijmaken door te verwijderen in een map waar iets overheen gekoppeld is. Je verwijdert dan uit het gekoppelde bestandssysteem, niet uit het bestandssysteem waarvan de bestanden eronder verborgen zitten.
• Een bestandssysteem tot precies 100 procent vullen. Zodra ook de rootreserve op is, falen diensten die hun logs of statusbestanden niet kunnen schrijven op verwarrende manieren. Houd marge.