Inhoud van een map op grootte analyseren

[anoniem]

Mijn complete /home van 500 MB zit vol. Waarschijnlijk wordt het veroorzaakt doordat ik mijn pc een keer bruut heb afgesloten, omdat gimp op hol sloeg. Vraag is hoe ik vanuit console (bij voorkeur) kan analyseren welke bestanden ruimte vreten.

[anoniem]

De boosdoener is gevonden. Idd een swap-bestand van Gimp, van wel: [code:1:b2bf977d2d] -rw------- 1 margree users 765673472 2003-03-09 17:40 gimpswap.2542 [/code:1:b2bf977d2d] En dat is sterk want: [code:1:b2bf977d2d] /dev/hda10 505132 504982 150 100% /home [/code:1:b2bf977d2d] Uitgaande van dat 1 kb 1024 bits is, dan past die swapfile er nog niet op.

[anoniem]

met [b:09414e9e3a]du[/b:09414e9e3a] kun je vanaf de prompt kijken welke mappen hoeveel ruimte innemen. Gimp kun je zodanig instellen dat deze zijn swap elders aanmaakt, bijv. in /tmp Rinse

[anoniem]

Inderdaad, met : du -h * kun je zien hoe groot alle * bestanden zijn.

[anoniem]

Heeft er iemand een verklaring voor het feit dat een bestand van 700 megabyte op een partitie van 500 mb past? De eerste weergave is van [b:8d164fd4e0]ls[/b:8d164fd4e0], de tweede met [b:8d164fd4e0]df[/b:8d164fd4e0]

[anoniem]

Rekenfoutje? Max

[anoniem]

De partitie is +/- 500 MB groot, dus [b:d7604a1f90]df[/b:d7604a1f90] geeft het juist weer. Dan zou [b:d7604a1f90]ls[/b:d7604a1f90] niet helemaal zuiver zijn.

[anoniem]

De inode tabellen worden gevuld met de bestandinfo (grootte), de schijfactie blijft echter doordat de disk eigenlijk vol is in de diskbuffer hangen - te wachten om geschreven te worden zodra er (weer) ruimte is. Dat is nooit gebeurd omdat de PC gecrashed/herstart is, terwijl de inode tabellen al wel 700Mb grootte aangeven, wat ls dus braaf laat zien. De data is uiteindelijk alleen niet op de disk terecht gekomen, en de buffer is weer leeg na de herstart...