[HP UX] directory met veel files verwijderen

[Kapoen]

Bij het verwijderen van files op een operationeel systeem ben ik het volgende probleem tegen gekomen:

/directoryX/ bevat een zeer groot aantal kleine bestandjes. Zoveel dat ' ls ' ontzettend traag is (het commando loopt al vrij lang en heeft nog altijd geen resultaten weergegeven).

Het is de bedoeling dat al deze files verwijderd worden aangezien ze niet meer relevant zijn en de directory in het geheel neemt teveel plaats in op de harde schijf van het systeem.

rm *, rm -r leveren geen resultaat op, beide geven als foutmelding dat de directory listing te lang is.
Het gebruik van rmdir leverde ook niets op, aangezien de directory hiervoor leeg moet zijn.
Verder heb ik ook nog mv * > /dev/null geprobeerd, maar ook hier waren er problemen met het aantal bestanden.

De handleiding van HPUX geeft alleen deze mogelijkheden aan om bestanden te verwijderen.

Zelf heb ik nog zitten spelen met ls a* of ls 0* om de selectie te beperken, maar blijkbaar
zijn de listings dan nog te groot.

Is er nog een andere mogelijkheid om van deze bestanden af te geraken?

*edit* Het gaat trouwens over een HP UX 11 systeem. HP UX systeemnaam B.11.11 9000/800 (tc)
verschijnt er bij de log in.

[ Voor 7% gewijzigd door Kapoen op 11-04-2006 11:44 ]

[Verwijderd]

Ken het probleem. Ik heb het altijd opgelost met

cd ..
rm -rf /directoryX/
mkdir directoryX

[Kapoen]

Helaas lijkt rm -rf ook gewoon vast te lopen op de hoeveelheid bestanden.
Ik heb het commando laten lopen en via een andere sessie op het systeem volg
ik de evolutie van de grootte van de directory. Deze blijft ongewijzigd.

Ik veronderstel dat het misloopt omdat al die commando's een soort van 'catalogus'
maken van de bestanden in de directory?

Om een idee te geven van het probleem: /directoryX/ bevat 179 megabytes aan gegevens
en de bestandjes zelf zijn maar enkele bytes groot. Hierna moet ik nog een vergelijkbare
directory leegmaken die grofweg 1 gigabyte groot is.

[Creepy]

heb je de beschikking over xargs? dan kan je iets doen als

code:

ls * | xargs rm

xargs zal dan rm voeren met de bestanden om te verwijderen.

[ Voor 26% gewijzigd door Creepy op 11-04-2006 12:03 ]

[blaataaps]

Ik neem aan dat als ls faalt, ls * net zo zal falen. Je kunt find proberen, die heeft wellicht een -exec functie zodat je ze 1 voor 1 kunt verwijderen, en anders find in combinatie met xargs rm. Als je de naam van de bestandjes ongeveer weet, zou je rm aaaa* kunnen proberen, hoewel dat mogelijk ook mislukt.
Als het op een apart filesystem is (zal wel niet) kun je overwegen opnieuw te mkfs'en, dat is in een dergelijk geval soms het snelste, maar uiteraard alleen bruikbaar als er voor de rest niks op dat filesystem staat.

[Verwijderd]

Heb je al geprobeerd om het met find te doen? Iets als find . -print -exec rm {} \;

[Verwijderd]

Een andere mogelijk is om bijvoorbeeld met winscp naar de directory te browsen en daar vanuit de bestanden te verwijderen. Enkel moet het wel mogelijk zijn om een ssh verbinding te maken.

[Bud_s]

wat mij ooit eens in een heel grijs verleden geholpen heeft op een motorola :

rm a*
rm b*

etc
Lezen is ook een vak ! zie ook blaataaps

[ Voor 20% gewijzigd door Bud_s op 11-04-2006 12:33 ]

[Kapoen]

Ja met die patronen heb ik het ook geprobeerd, maar dat lukte dus niet
omdat de bestandjes blijkbaar niet met a..z of 0..9 beginnen.

Maar find geeft wel resultaten. Als ik gewoon find directoryX ingeef dan
krijg ik wel een listing van de bestanden. Dus ik zal dit combineren met de -exec
optie om het probleem op te lossen

Bedankt allemaal

Overigens vind ik het wel raar dat 'find' resultaten geeft en 'ls' niet, waar
zit het verschil tussen de 2 commando's?

[TD-er]

Kapoen schreef op dinsdag 11 april 2006 @ 13:09:
Ja met die patronen heb ik het ook geprobeerd, maar dat lukte dus niet
omdat de bestandjes blijkbaar niet met a..z of 0..9 beginnen.

Maar find geeft wel resultaten. Als ik gewoon find directoryX ingeef dan
krijg ik wel een listing van de bestanden. Dus ik zal dit combineren met de -exec
optie om het probleem op te lossen

Bedankt allemaal

Overigens vind ik het wel raar dat 'find' resultaten geeft en 'ls' niet, waar
zit het verschil tussen de 2 commando's?

Find geeft tussentijdse resultaten per regel. ls wil eerst de complete lijst hebben en die mogelijk nog wat layouten (langste naam in een kolom bepaalt de breedte). Dus ls was nog gewoon bezig.

De reden dat 'rm' niet werkte met 'rm *' is dat je shell (bash of csh oid) dan een enorm lange regel te verwerken krijgt en dat 'ie dus uit de buffer loopt.
Zoals al eerder aangegeven kun je met xargs dus de input in stukjes hakken en voeren aan een programma.

Bijv
ls |xargs -n2 echo
zal de filenamen netjes per 2 printen.

Maar goed, die find zal wel werken, ook al duurt 'ie waarschijnlijk erg lang.

[Kapoen]

Find is inderdaad langzaam. Ik ben ook bezig met de xargs optie en dat werkt even goed
Weliswaar ook vrij langzaam, maar dat komt waarschijnlijk door de enorme hoeveelheid aan bestanden.

[Bud_s]

Beter langzaam dan helemaal niet Het voordeel is dat het apparaat het moet doen , en niet jij zelf

[Kapoen]

Inderdaad

De directory van 179 megabyte is in ieder geval leeg na een dik kwartiertje aan 10 files per rm.
Nu de directory van 1 gig nog.

Overigens ben ik wel van plan om de crontab aan te passen zodanig dat dit niet meer
voorvalt. Gewoon dagelijks om middernacht of zo de boel laten schoonmaken...

[webfreakz.nl]

Ik weet niet wat voor software je gebruikt, maar misschien handig om te kijken hoe die beter met bestanden kan omgaan?

[Kapoen]

Het pakket/systeem verantwoordelijk voor deze rommel is helaas vrij gesloten
waardoor ik weinig tot geen mogelijkheden heb om het probleem bij de bron aan te pakken.

[zomertje]

Verwijderd schreef op dinsdag 11 april 2006 @ 11:17:
Ken het probleem. Ik heb het altijd opgelost met

cd ..
rm -rf /directoryX/
mkdir directoryX

Meestal deed ik dit ook, of inderdaad een scriptje met find bakken

[jvhaarst]

Is het niet mogelijk om een filesysteem te gebruiken dat wel met grote aantallen files overweg kan ?
Wij hebben hier ook zoiets gehad, maar na van ext2 op ext3 te zijn overgestapt was het een stuk minder problematisch.

[TD-er]

jvhaarst schreef op vrijdag 14 april 2006 @ 22:36:
Is het niet mogelijk om een filesysteem te gebruiken dat wel met grote aantallen files overweg kan ?
Wij hebben hier ook zoiets gehad, maar na van ext2 op ext3 te zijn overgestapt was het een stuk minder problematisch.

Het enige verschil tussen ext2 en ext3 is toch alleen de toevoeging van journaling?
Oftewel dat is iets veiliger in het geval van crashes of het plots offline gaan van je filesysteem.
Qua performance zou dat dus geen winst moeten opleveren.

[zomertje]

jvhaarst schreef op vrijdag 14 april 2006 @ 22:36:
Is het niet mogelijk om een filesysteem te gebruiken dat wel met grote aantallen files overweg kan ?
Wij hebben hier ook zoiets gehad, maar na van ext2 op ext3 te zijn overgestapt was het een stuk minder problematisch.

Dat is niet altijd even makkelijk. Ik weet niet hoe het bij TS zit, maar als je over een productieserver praat is het waarschijnlijk een no-go Alleen als je helemaal aan het begin die kans krijgt, dan is het mogelijk natuurlijk Ofwel een workaround is gewoon veel makkelijker.

[teh_twisted]

anders miss dit proberen, als je 't andere te langzaam vind, dit is evt. sneller:

code:

for i in *; do rm -f $i; done

[zomertje]

Moet dat niet zijn:

code:

for i in $(ls *); do rm -f $i; done

En als root op een hp-ux hoef je die -f zelden te gebruiken

[ Voor 30% gewijzigd door zomertje op 15-04-2006 08:40 ]

[teh_twisted]

hangt er vanaf, ik weet iig dat onder bash, zsh en volgensmij ook csh for i in * gewoon genoeg is...

[moto-moi]

jvhaarst schreef op vrijdag 14 april 2006 @ 22:36:
Is het niet mogelijk om een filesysteem te gebruiken dat wel met grote aantallen files overweg kan ?
Wij hebben hier ook zoiets gehad, maar na van ext2 op ext3 te zijn overgestapt was het een stuk minder problematisch.

ext3 kan net zo slecht omgaan met directories met veel files als ext2 hoor
65535 is geloof ik de maximale hoeveelheid, reiser of XFS/JFS is dan wel een optie, die hebben dat probleem niet