[LINUX] Geen vrije ruimte na rm file

[FaZe]

Hey mensen,
Heb het volgende probleem al een tijd.
Heb Redhat 7.3 met etx3 filesystem. En als ik dus een file verwijder (bijv een van 700MB) dan krijg ik niet de ruimte vrij (volgens "df") ook volgens andere programma's niet. Al zit mn hd vol en gooi ik er 2 Gig vanaf, dan blijft ie zeggen dat ie vol zit.

als ik bijv in /home "du -h" doe, staat er :3.9 gig used
maar "df -h" zegt: 6 Gig used.

Zwaar irritant dus. Een reboot lost alles steeds op (denk door de fsck gewoon) maar dat is geen oplossing.

Iemand een idee? Is er een commando om hem zelf zeg maar de tabel bij te laten werken ofzo ZONDER te unmounten?

Heb het probleem zowel bij een "rm" in console als bij het deleten via bijv FTP of SAMBA

[deadinspace]

It's a feature, not a bug

Als een programma een file geopend heeft, en jij verwijdert die file, dan wordt de filenaam wel uit de directory verwijderd, maar de filedata zelf blijft nog bestaan, zodat het programma dat die file open had er nog gewoon naar kan lezen en schrijven. Op het moment dat geen enkel programma de file nog geopend heeft, verwijdert de kernel ook de file data zelf. Pas op dat moment krijg je de ruimte erbij.

Dat verklaart ook waarom een reboot het oplost: tijdens het afsluiten worden alle programma's afgesloten, en dus wordt dan ook de ruimte vrijgegeven.

[Kees]

En als je bijvoorbeeld dus je apache logs verwijderd moet je dus je apache restarten. Hierdoor worden de open files gesloten en opnieuw geopend/aangemaakt. Dit is idd standaard gedrag zoals dis hieboven meldt

(en maar goed ook, anders zou een programma redelijk snel crashen als je een file verwijderd, ook is dit (imho) beter dan win2k waarbij je gewoon een melding krijgt dat de file open is en dus niet verwijderd kan worden. dan moet je eerst een programma afsluiten, file verwijderen en prog wer starten, dat neemt altijd meer tijd in beslag dan de linux manier )

[FaZe]

maar is er ook een commando dat ie hem WEL verwijderd? Heb een p2p service er draaien waar het steeds geshared wordt als een download klaar is...en om die nu iedere keer te rebooten en servers te laten zoeken enzo is beetje irri..

[Verwijderd]

misschien rm -rf gebruiken om het bestand te verwijderen?

[PipoDeClown]

is het niet te verhelpen met zoiets als "sync"?
want rebooten van een os gaat me iets te ver (tis geen windows kom nou )

[blaataaps]

met lsof kijken welk proces het bestand nog open heeft, dat programma afsluiten/herstarten. Als alle verwijzingen naar het bestand 'weg' zijn, zal het automagisch verwijderd worden.

[FaZe]

ja maar ik weet welk programma dit doet (mldonkey) maar aangezien die met veel servers connect en files gaat hashes wat soms wel een half uur kan duren is afsluiten/herstarten geen optie

[kenneth]

rm -rf werkt niet (waarom die -r? Het is toch geen directory?)
sync werkt ook niet

Misschien dat je de file kan truncaten, voor je hem delete?
In de shell als volgt:

code:

 > /path/to/file/liedje.mp3

[Verwijderd]

PipoDeClown schreef op 27 oktober 2002 @ 10:37:
(tis geen windows kom nou )

nee inderdaad daar zou je de file niet eens kunnen verwijderen !

willen jullie graag dat je systeem onstabieler wordt ofzo? je gaat toch geen files van je programma afpakken zonder dat hij weet dat hij ze kwijt is niet meer dan logisch deze functionaliteit als je het mij vraagt...

[blaataaps]

mithalph schreef op 27 oktober 2002 @ 16:26:


Misschien dat je de file kan truncaten, voor je hem delete?
In de shell als volgt:

code:

 > /path/to/file/liedje.mp3

En waarom zou dat helpen precies? : )
De filedescriptor van mldinges zal daar verder niet wakker van liggen hoor : )

[Denhomer]

blaataaps schreef op 27 oktober 2002 @ 17:44:
[...]

En waarom zou dat helpen precies? : )
De filedescriptor van mldinges zal daar verder niet wakker van liggen hoor : )

Omdat de file size dan tot 0 bytes gereduceerd wordt

[Verwijderd]

Denhomer schreef op 27 oktober 2002 @ 17:58:
[...]


Omdat de file size dan tot 0 bytes gereduceerd wordt

Voor nieuwe access tot dat bestand wel ja

Tja, hier zal weinig anders opzitten, dan het progje opnieuw te starten.
/me snapt het hele probleem toch niet zo. Half uurtje wachten voor dat programma is toch niet zo'n probleem

[deadinspace]

Verwijderd schreef op 27 oktober 2002 @ 18:17:
Voor nieuwe access tot dat bestand wel ja

Niet alleen voor nieuwe access. Als je een file truncate, dan wordt dat onmiddelijk doorgevoerd, ook voor programma's die die file al geopend hadden.
Dit is ook de manier waarop logrotate de logs roteert: hij kopieert de logfile naar logfile.0, en truncate dan logfile.

Dit is overigens wel iets dat vervelend kan zijn voor programma's. De ene keer kun je nog lezen van de file, de andere keer zit je ineens voorbij het einde van de file, terwijl de file groot genoeg zou moeten zijn?
Als het programma ranzig geschreven is kan het daar dus van op zijn bek gaan.