[ext3] Linux root partitie vol

[eborn]

Ik heb een vreemd probleem. Op mijn servertje heeft de root-partitie standaard zo'n 500 mb vrij. Verder zitten er nog 2 andere schijven in (1 voor backup en 1 voor filesharing).

Nu heb ik sinds kort ext2 vervangen door ext3. Alles ging goed. Alleen heb ik de laatste tijd last van het feit dat MySQL een logbestand van 250 meg aanmaakt Geen probleem op het eerste gezicht. Gewoon even delete en dan heb ik weer ruimte zou je denken. Maar die ruimte komt niet meer vrij. Het is zelfs zo erg dat mijn root partitie nu gewoon vol staat! Met alle gevolgen voor het goed functioneren van enkele servers. Dat MySQL probleempje los ik wel op, maar waar blijven mijn mb's?

Vorige keer heb ik het met een geforceerde e2fsck bij het rebooten gedaan, maar dit moet geen gewoonte worden. Iemand een idee?

voor de volledigheid:

$ mount

/dev/hda1 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hdc1 on /home type ext3 (rw,errors=remount-ro)
/dev/hdd1 on /backup type ext3 (rw,errors=remount-ro)

$ df

Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda1 1011928 977224 0 100% /
/dev/hdc1 3016144 1074356 1788576 38% /home
/dev/hdd1 597103 198596 367664 36% /backup

[Verwijderd]

Weet je zeker dat die logfiles die ruimte innemen, misschien zijn er nog andere files die die ruimte innemen.
Doe eens een 'du -sh /' en kijk of er echt 1gb aan data op je schijf staat. Zo niet dan zou het een kernel-probleem kunnen zijn. Welke kernel draai je, die e2fsck gaf die nog problemen aan, maakte die ruimte vrij?

[ecageman]

Als je een bestand weg haalt dat nog in gebruik is door een proces, dan komt die ruimte niet vrij. Als je nu mysql stopt, dan zul je zien dat je ruimte er ook weer is.

[eborn]

Ok, ik heb de server even gereboot en nu heb ik i.i.g. weer 250 meg vrij (zo groot was het log bestand). Maar gisteren had ik nog 600 mb vrij en ik weet 100% zeker dat er geen bestanden op zijn gezet. Dit was vorige keer ook zo. Toen was de MySQL log ook opeens 250 mb (in één nacht). Toen ik die verwijderde en opnieuw opstarte had ik opeens weer 600 mb vrij

e2fsck gaf i.d.d. allemaal (fout)meldingen. Vooral meldingen als 'wrong timestamp on inode xxx' o.i.d. En aan het einde van de check kwam er nog een gigantische lijst met nummers tussen haakjes, iets als: (-10030424),(13437482),(23434134),etc...

Ik gebruik kernel 2.4.18

[Kees]

kijk ook even WAT er in de log staat, dan kun je er mischien iets mee doen.

Verder, voor je mysql's log weer wil verwijderen: verwijder hem, en flush daarna de logs (zie manual voor de flush syntax).

Kijk ook in je /var/log om te zien wat daar allemaal aan logs staat, en instaleer logrotate.

[eborn]

Logrotate staat aan, maar op de één of andere manier krijg ik dus 's nachts opeens die mega-grote log. Ik zal hem de volgende keer weer even nalopen (want ik verwacht wel dat hij nog een keer langs komt )

[Heidistein]

En natuurlijk is het mogelijk dat MySQL its niet goed vond, een logentry aanmaakte, en een bestandje in /tmp zette.
Kijk ook vooral daar wat daar staat

[deadinspace]

Op woensdag 27 maart 2002 15:29 schreef eborn het volgende:
Ok, ik heb de server even gereboot en nu heb ik i.i.g. weer 250 meg vrij (zo groot was het log bestand). Maar gisteren had ik nog 600 mb vrij en ik weet 100% zeker dat er geen bestanden op zijn gezet. Dit was vorige keer ook zo. Toen was de MySQL log ook opeens 250 mb (in één nacht). Toen ik die verwijderde en opnieuw opstarte had ik opeens weer 600 mb vrij

Wel dit lezen he:

Op woensdag 27 maart 2002 15:23 schreef ecageman het volgende:
Als je een bestand weg haalt dat nog in gebruik is door een proces, dan komt die ruimte niet vrij. Als je nu mysql stopt, dan zul je zien dat je ruimte er ook weer is.

Een reboot was dus niet nodig geweest.
En misschien is het verstandig om uit te zoeken waarom mysql ineens zoveel logs genereerde.

[eborn]

Op woensdag 27 maart 2002 18:36 schreef deadinspace het volgende:

[..]

Wel dit lezen he:
[..]

Een reboot was dus niet nodig geweest.
En misschien is het verstandig om uit te zoeken waarom mysql ineens zoveel logs genereerde.

Ja, dat moet ik nog uitzoeken. Maar wat je zei over dat ik beter moest lezen slaat nergens op Het ging namelijk niet om dat die 250 MB weer vrij kwam. Maar na de reboot (en e2fsck) kreeg ik totaal 600 MB vrij. Da's 350 MB meer dan dat logbestand groot was. Wat ik me dus afvroeg was hoe dat opeens kon verdwijnen.

[deadinspace]

Op donderdag 28 maart 2002 13:35 schreef eborn het volgende:

[..]

Ja, dat moet ik nog uitzoeken. Maar wat je zei over dat ik beter moest lezen slaat nergens op Het ging namelijk niet om dat die 250 MB weer vrij kwam. Maar na de reboot (en e2fsck) kreeg ik totaal 600 MB vrij. Da's 350 MB meer dan dat logbestand groot was. Wat ik me dus afvroeg was hoe dat opeens kon verdwijnen.

/tmp ?

[eborn]

Zo schoon als maar kan, ook met een ls -a

[odysseus]

Kijk eens welke directories er erg groot zijn. Met iets als 'du -h --max-depth=1 /' zie je hoe groot /tmp, /var, /usr en dergelijke zijn. Je kijkt gewoon in alles wat >300MB is en voert daar het commando nog eens uit (zonder '/' aan het eind). Op die manier moet je er snel genoeg achter kunnen komen waar die schijfruimte heen is. Kijk ook even of er niet een heel groot bestand in je / staat, dat zou natuurlijk ook nog kunnen en je vangt hem dan niet met zo'n du-commando.

[deadinspace]

Op vrijdag 29 maart 2002 14:25 schreef eborn het volgende:
Zo schoon als maar kan, ook met een ls -a

Ja, maar ik bedoelde dus dat daar een hoop gestaan kan hebben. /tmp wordt namelijk tijdens het booten geleegd. Als MySQL (die maakte ineens ook een huge logfile, dus als daar iets raars mee was dan is het ook mogelijk dat MySQL veel ruimte gebruikte in /tmp, en dat is na een reboot weg ja.