# Grote bestanden op de Mac vinden zonder de verkeerde te wissen
> Houd rekening met APFS-snapshots, klonen en opschoonbare ruimte, en classificeer grote bestanden op eigenaar voordat je ze verplaatst of verwijdert.
Published: 2026-06-07 | Updated: 2026-10-18
De snelste manier om te zien wat een schijf gebruikt, is die te meten, niet map voor map in Finder
te bladeren. Meten heeft nog steeds uitleg nodig: een Foto's-bibliotheek van 40 GB is
niet hetzelfde als een installer van 40 GB, en APFS-snapshots, klonen en opschoonbare capaciteit
kunnen twee correcte hulpmiddelen totalen laten rapporteren die er verschillend uitzien.
Zo wordt schijfruimte geboekt, zo meet je die, en zo vind je de
grote items veilig.
## Waarom je schijf vol is maar de bestanden niet optellen
Moderne Macs gebruiken het bestandssysteem APFS, en APFS rapporteert ruimte anders dan
wat Finder toont. Twee categorieën verbergen gigabytes:
- **Lokale snapshots.** Time Machine bewaart momentopnamen van je schijf op
de interne schijf tussen back-ups. Ze pinnen de ruimte van bestanden die je al
hebt verwijderd, omdat de snapshot er nog naar verwijst, tot macOS ze
uitdunt. Apple zegt dat snapshots per uur normaal ongeveer 24 uur worden bewaard en
[automatisch worden verwijderd](https://support.apple.com/102154) naarmate ze verouderen of wanneer ruimte
nodig is. Toon ze met:
```
tmutil listlocalsnapshots /
```
- **Opschoonbare ruimte.** APFS markeert caches, lokale snapshots en opnieuw te downloaden
inhoud als opschoonbaar: ruimte die macOS zelf terugneemt wanneer iets die nodig heeft.
macOS kan dit als beschikbaar tellen, en Finder kan het in het beschikbare
totaal meenemen. Je kunt het niet betrouwbaar met de hand wissen.
Controleer de getallen met:
```
df -h /
diskutil apfs list
diskutil apfs listSnapshots /
```
`df` meldt wat het gekoppelde bestandssysteem als gebruikt en beschikbaar beschouwt;
`diskutil apfs list` toont de gedeelde container, de volumes en de resterende
capaciteit; `diskutil apfs listSnapshots /` toont snapshots die aan het opstart-volume hangen. Wanneer Finder zegt dat de schijf voller is dan je bestanden verklaren, helpen deze weergaven
gewoon bestandsgebruik te scheiden van snapshots en gedeelde APFS-capaciteit.
## Meet echt gebruik vanaf de opdrachtregel
Om de zware mappen te vinden is `du` (schijfgebruik) het kernhulpmiddel. Vanuit je thuis-map:
```
du -sh ~/* ~/Library 2>/dev/null | sort -h
```
`-s` geeft een samenvatting per item, `-h` drukt menselijk leesbare groottes af, en doorsturen naar
`sort -h` zet de grootste achteraan. Duik één groot resultaat tegelijk in. Terminal kan
Volledige schijftoegang nodig hebben voor beschermde appgegevens, en een scan van de thuismap kan lang
duren wanneer die cloudmappen of ontwikkelaarsbomen kruist.
Het getal is niet altijd fysieke toewijzing. Hard links geven meerdere namen aan hetzelfde
onderliggende bestand, en APFS-klonen delen blokken tot één kopie verandert. Map-totalen en vrije ruimte van de container kunnen daarom verschillende vragen beantwoorden. Gebruik `du` om
kandidaten te vinden, en gebruik daarna Info van Finder en de APFS-capaciteitsweergave voordat je een
verwijdering met grote impact doet.
Om losse grote bestanden te vinden in plaats van mappen, filtert `find` op grootte:
```
find ~/Downloads ~/Movies ~/Desktop -type f -size +500M -print 2>/dev/null
```
Begin bij mappen die je zelf beheert in plaats van de hele thuismap te scannen. Het
commando kan vergeten video-exports, schijfkopieën en archieven vinden, maar deze mappen
kunnen nog steeds databases of cloudgesynchroniseerde bestanden bevatten. Breid de wortels alleen uit wanneer dat nodig is.
Voor een interactieve terminalkaart kan `ncdu` een gekozen map op grootte doorbladeren. Behandel het
eerst als een alleen-lezen ontdekkingshulpmiddel; toon een kandidaat in Finder en verplaats die naar de Prullenmand
nadat je die hebt herkend, in plaats van vanuit een onbekende boom in `ncdu` te verwijderen.
## Win de verborgen ruimte terug
Als snapshots of opschoonbare ruimte het probleem zijn in plaats van één bestand,
geeft het vrijmaken van echte ruimte die je zelf beheert macOS ruimte terwijl het lokale
snapshots en opschoonbare caches vanzelf laat verouderen of uitdunt. Een Time Machine-schijf opnieuw aansluiten maakt
meer back-upgeschiedenis beschikbaar, maar het is geen commando dat snapshots met de hand wist. Je
hoeft zelden een van beide categorieën met de hand te forceren.
## Een visuele kaart, wanneer een lijst niet genoeg is
Een treemap van de thuismap: de grootste mappen zijn de grootste blokken, en een klik duikt in elk ervan. Dit is de Analyseweergave van Mole.
Groottes in een terminal zijn nuttig, maar lastig in je hoofd te houden over een hele schijf.
Een treemap lost dat op door elke map als een rechthoek te tekenen die op grootte is geschaald,
zodat de grootste dingen de grootste blokken zijn en één blik toont waar het gewicht
zit. De Analyseweergave van [Mole](https://mole.fit/) is een grafische tegenhanger van de padwandeling
hierboven: die brengt de hele schijf vanaf de root in kaart, duikt in met een klik, en laat je
een item in Finder tonen of naar de Prullenmand sturen (vanuit het menu van de rechtermuisklik, met een
groottebevestiging, en te herstellen tot de Prullenmand leeg is). Navigatiewortels
zoals je thuismap hebben geen verwijderoptie, dus een verkeerde klik kan niets
structureels weghalen. Gebruik wat je wilt; de treemap en de commando's beantwoorden dezelfde
vraag.
## Onder de motorkap: hoe een schijfanalysator snel blijft
Je hebt dit deel niet nodig om ruimte vrij te maken, maar als je je ooit hebt afgevraagd waarom een
goede schijfkaart in seconden terugkomt waar een naïef script kruipt, hier is de vorm
ervan. Het voorbeeld is [het open-source opdrachtregelhulpmiddel van Mole](https://github.com/tw93/Mole),
specifiek de Go-analysator in `cmd/analyze`. De native app heeft een aparte Swift-scanner, maar beide houden gelijktijdigheid begrensd en ontdubbelen hard links.
In de CLI-analysator begrenst de wachtrij wachtend werk, aparte budgetten begrenzen mapwandelaars en du-processen, ontdubbeling van hard links telt elke byte één keer, en Top-N-heaps voorkomen dat de hele boom wordt gesorteerd.
De langzame manier is de voor de hand liggende: loop elke map langs, `stat` elk bestand, tel alles
op, en sorteer daarna. Op een thuismap met miljoenen kleine bestanden is dat zowel traag
als geheugenhongerig. De scanner vermijdt beide vallen met drie ideeën.
**Begrensd, maar niet met één limiet.** Naïef parallellisme start een goroutine per
map en smelt de schijf. De scanner houdt aparte budgetten voor aparte
bronnen: een pool mapwerkers (2 tot 12, geschaald naar je cores), een
veel kleinere pool van hoogstens vier gelijktijdige `du`-subprocessen (omdat te veel
concurrerende mapwandelingen de schijf-I/O kunnen verzadigen), en een
wachtrijgrens zodat wachtend werk nooit opzwelt tot duizenden gestapelde goroutines.
Die tot één limiet samenvoegen is hoe schijfhulpmiddelen traag of
geheugenhongerig eindigen.
**Houd alleen de winnaars.** Je wilt de grootste mappen, niet allemaal, dus de
scanner sorteert nooit de hele schijf. Die stroomt elk gemeten item door twee
min-heaps, één met de top 30 mappen en één met de top 20 bestanden. Wanneer een heap
vol is, wordt een nieuw item vergeleken met de kleinste overlever en weggegooid als het die
niet verslaat. Dat is ongeveer lineair in het aantal bestanden en houdt maar een paar
tientallen items in het geheugen, in plaats van miljoenen te sorteren.
**Tel elke byte één keer.** Een bestand met meerdere hard links zou anders
één keer per link worden opgeteld. De scanner noteert het paar `(device, inode)` van elk bestand de eerste
keer dat het dat ziet en slaat de herhalingen over, en zo komen de totalen overeen met `du`. Die weigert
zelfs een maptotaal te cachen dat van deze ontdubbeling afhing, omdat dat getal
afhangt van de scanvolgorde en een latere losse herscan zou vergiftigen.
Niets hiervan is exotisch. Het is het verschil tussen een hulpmiddel dat "wat vult
mijn schijf" efficiënt beantwoordt en een hulpmiddel dat middelen besteedt aan het beheren van de scan zelf.
Deze details beschrijven de CLI; de native treemap hierboven gebruikt een eigen Swift-scanner.
## Classificeer voordat je iets verwijdert
Een groot item vinden is geen toestemming om het te verwijderen. Zet elke kandidaat in één van
drie bakken:
- **Vervangbaar:** gecontroleerde installers, reproduceerbare builduitvoer en gedocumenteerde
caches. Controleer de kosten van opnieuw downloaden of herbouwen voordat je ze verwijdert.
- **Persoonlijk of operationeel:** foto's, berichten, projectarchieven, schijven van virtuele
machines, modelgewichten en apparaatback-ups. Exporteer, back-up of neem deze uit dienst via
de app die eigenaar is.
- **Door een app of het systeem beheerd:** pakketdatabases, containers, bibliotheken van Foto's of Mail,
snapshots, en alles onder `/System`. Gebruik de bediening van de app of laat
het met rust.
Als een grote map bij een app hoort die je niet meer gebruikt, volg dan de gedocumenteerde
uninstaller en [bekijk daarna de restanten](https://mole.fit/nl/blog/how-to-completely-uninstall-apps-on-mac).
Verplaats gewone bestanden eerst naar de Prullenmand en laat ze daar tot de betrokken app en
het project nog werken. De Prullenmand legen is de onomkeerbare stap.
Voor de bredere opschoning voorbij losse grote bestanden, zie
[hoe je ruimte vrijmaakt zonder bestanden te verliezen](https://mole.fit/nl/blog/how-to-free-up-space-on-mac).
## Een herhaalbare methode
Vergelijk eerst `df`, de APFS-capaciteit en de opslaginstellingen, zodat je weet of het probleem
echte fysieke druk is of classificatie. Meet daarna gekozen wortels, duik in
de grootste tak, en classificeer de kandidaat op eigenaarschap en herstelbaarheid. Verwijder
eerst vervangbare gegevens, handel persoonlijke gegevens af via back-ups en de apps die eigenaar zijn, en houd
gewone verwijderingen herstelbaar in de Prullenmand tot je het resultaat hebt gecontroleerd.
---
Canonical HTML page: https://mole.fit/nl/blog/how-to-find-large-files-on-mac
Blog index for agents: https://mole.fit/nl/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
