Jede Menge Dateien löschen

  • Thread starter Thread starter Deleted member 11691
  • Start date Start date
D

Deleted member 11691

Guest
Hallo,

folgendes Problem: Durch einen Scriptfehler hat Bash nicht 5 Millionen zufällige Zeichenketten in eine Datei sondern einen Dateinamen in 5 Million Dateien mit zufälligen Zeichenketten im Dateinamen geschrieben.
Nun habe ich ~5 Million Dateien in einem Verzeichnis und möchte diese so schnell als möglich löschen.
Habe folgende Scripte jeweils 1 Stunde lang durchlaufen lassen, haben allerdings nicht viel bewirkt:
rm -vR * (Hat garnicht funktioniert, da zu viele Argumente)
find -type f -delete (Gibt keine Ausgabe, Übersicht, etc. und ist zu langsam)
for i in *
do
echo -n "."
unlink $i
done (Ist zu langsam)
So, nun das Problem: Es existieren, trotz ca. 2 Stunden Laufzeit dieser Befehle, immer noch ~4 Million Dateien.
Wie kann ich diese mit einem Befehl so schnell als möglich löschen?

L.G. PCFreund
 
Versuchs damit:
Code: 
find /pfad/zum/verzeichnis -maxdepth 1 -type f | xargs -n5000 -P5 rm -f
Vorsicht: Löscht alle Dateien in dem Verzeichnis! Wenn da noch benötigte Dateien drin vorkommen, sollten die vorher gesichert werden.
Es erfolgt keine Ausgabe, beim löschen von 5 Millionen Dateien solltest du je nach verwendetem Dateisystem schon 3-4 Stunden einplanen.

Einige werden eventuell "find" mit Parameter "-exec rm" vorschlagen. Zu empfehlen ist das nicht. Das erzeugt für jede einzelne Datei einen rm Prozess, was bei 5 Millionen Dateien verdammt viel Zeit kostet.
 
So, dann melde ich mich auch 'mal zurück:
Habe den Befehl über Nacht laufen lassen und die Dateien sind alle weg :)
Vielen vielen Dank!
 
@Firewire2002:
Wie ist es möglich deinen zitierten Befehl möglichst performanceschonend ausführen zu lassen? Dieser Befehl frist sehr viel Geschwindigkeit, indem meine Seiten mit relativ hohen Antwortzeiten reagieren.
 
Code: 
man ionice
man nice

ansonsten - auch wenn schon längers her und gelöst: machmal ist' einfacher, die noch notwendigen Dateien wegzukopieren und einfach das Verzeichnis zu löschen...
 
Danke marce. Ich probiere das mal aus.

Bei mir handelt es sich um 200 Mio. Dateien. Eine etwas andere Volumenkategorie, indem verschieben nicht hilft, da man den Ordner auch nicht mehr einsehen kann, weil es nur rechnet.
 
Hat leider kein Erfolg gebracht.

Ich starte die Prozesse in "screen" und lastet meinen Server extremst aus, auch mit "nice".

Beispiel:
load average: 43.81, 34.18, 29.59

Normal sind:
load average: 00.09, 00.07, 00.08

Wie gehe ich vor:

screen -dmS cleanup
screen -r cleanup
find /pfad/zum/verzeichnis -maxdepth 1 -type f | xargs -n5000 -P5 rm -f
renice -n -19 -p PID
 
Last edited by a moderator:
wenn Du jetzt auch noch verraten würdest, wie Du es gemacht hast und welchen nice-Level zu gewählt hast könnte man Dir vielleicht sogar noch helfen...
 
Ja, sehr sicher. Weil bei "top" dann folgendes stand:

PR: 39 (statt 20)
NI: 19 (statt 0)
S: D (statt S)

Edit:
Es geht um command "find". Lief alles super. Später kam dann aber "rm" selbstständig dazu und bremste aus. Aber als ich auch die commands "rm" drosselte, änderte sich nichts.
 
200 Millionen in einem Verzeichnis? Manchmal muss ein Admin halt auch mal bestraft werden. ;)
ionice könnte bessere Ergebnisse liefern, als "nice". Ein nachträgliches renice auf die rm ist sinnfrei, weil die sowieso immer wieder neu gestartet werden. In meinem Beispiel oben aller 5000 Dateien.
Der Befehl ist nun mal für schnellstes Löschen ausgelegt und das zieht nun mal auch Performance. Bei 200 Millionen Dateien dürfte aber auch der find schon einiges an Zeit benötigen, bis er anfängt Dateien aufzulisten.

Man könnte den find in kleinere Stückchen unterteilen, so dass er insgesamt nur Anzahl X an Dateien verarbeitet und danach abbricht. Damit könnte man zumindest den restlichen Anwendungen ein bisschen Luft verschaffen, auch wenn es sie trotzdem ausbremsen wird.

Aber 200 Millionen ist eine Hausnummer. Hier muss man etwas rumprobieren, was am besten funktioniert.
Nur werde ich nun kein Testsystem mit 200 Millionen Inodes aufsetzen, um dafür die optimale Lösung zu suchen. ;)
 
Quick, extrem dirty und absolut nicht weiterzuempfehlen:
Code: 
mkdir /tmp/dontdothisagain
mount -t tmpfs /tmp/dontdothisagain
mv /path/to/remove /tmp/dontdothisagain
umount /tmp/dontdothisagain

Man könnte in diesem speziellen Fall auch mit tar rumhacken, ist aber nur minimal schneller als find+xargs+rm


Allgemein: Housekeeping sollte man nicht erst betreiben, wenn es zu spät ist...
 
Ich hab es nun nicht ausprobiert, aber bist du dir sicher, dass dies nicht noch aufwendiger wäre als der find+xargs+rm?
Durch das tmpfs hast du einen Bruch des Filesystems. Somit muss er die Dateien kopieren und auf dem alten entfernen. Einfaches Umlinken der Inodes funktioniert in diesem Falle nicht mehr.
 
Ich weiß nicht, ob es wirklich 200 Mio. Dateien sind. Ich kann das auf 2 Jahre auf die Gegebenheiten nur hochrechnen. Ein "ls" funktioniert ja nicht mehr. Selbst nach 24 Stunden ist dieser Prozess noch aktiv. Auch weiß ich, dass das meine schuld ist. Jeder Mensch hat seine Stärken woanders und mir ist das in 2 Jahren nie aufgefallen, da ich auch kein absoluter Experte in diesem Gebiet bin und mich auch nicht täglich damit beschäftige. ;)

Dennoch danke für eure Hilfe. Sollte sich keine Lösung finden, müssen die Dateien drauf bleiben. Ich werde wahrscheinlich am Montag eure weiteren Tipps nochmal versuchen anzuwenden. :)
 
Mit "df -i" könntest du zumindest nachschauen, wieviele Inodes in dem Dateisystem insgesamt genutzt sind. Wenn man mit so einem Ordner rechnet, sollte der ja einen Großteil der Gesamtmenge ausmachen.

Hier kämen einem auch wieder mehrere Partitionen zu Gute. Dann würde ich vorschlagen, die noch benötigten Daten von der Partition zu sichern und das betroffene Verzeichnis auszulassen. Partition neu formatieren und Daten wieder zurück kopieren.
 
Firewire2002 said:
Ich hab es nun nicht ausprobiert, aber bist du dir sicher, dass dies nicht noch aufwendiger wäre als der find+xargs+rm?
Durch das tmpfs hast du einen Bruch des Filesystems. Somit muss er die Dateien kopieren und auf dem alten entfernen. Einfaches Umlinken der Inodes funktioniert in diesem Falle nicht mehr.
Click to expand...
Ich habe es interessehalber in einer FreeBSD-VM (exakt so aufgesetzt allerdings mit 8GB RAM, Host und VM waren "idle") mit 1Mio Textfiles getestet:
Code: 
[root@freebsd:~] # mkdir /data/unlinktest ; cd /data/unlinktest
[root@freebsd:/data/unlinktest] # /usr/bin/time -p /bin/sh -c 'for i in `seq 1000000` ; do echo $i > $i.txt ; done'
real 5288.75
user 18.01
sys 4992.17
[root@freebsd:/data/unlinktest] # /usr/bin/time -p find /data/unlinktest -maxdepth 1 -type f | xargs -n5000 -P5 rm -f
real 819.10
user 0.41
sys 4.23
[root@freebsd:/data/unlinktest] #
Dann ein Reboot der VM um gleiche Ausgangsbedingungen zu schaffen:
Code: 
[root@freebsd:~] # mkdir /data/unlinktest ; cd /data/unlinktest
[root@freebsd:/data/unlinktest] # /usr/bin/time -p /bin/sh -c 'for i in `seq 1000000` ; do echo $i > $i.txt ; done'
real 5165.63
user 17.88
sys 4869.05
[root@freebsd:/data/unlinktest] # mkdir /tmp/unlinktest ; mount -t tmpfs -o size=4294967296 tmpfs /tmp/unlinktest
[root@freebsd:/data/unlinktest] # /usr/bin/time -p mv -f /data/unlinktest /tmp/unlinktest
^Ctime: command terminated abnormally
real 8156.40
user 0.00
sys 0.00
Versuch nach rund zwei Stunden abgebrochen. Es waren erst ~490000 INodes im tmpfs geschrieben und kein INode im Quellverzeichnis gelöscht.
find+xargs+rm ist also doch erheblich schneller. Da habe ich wohl einen Anwendungsfall gewaltig verhexelt, sorry.

Anzumerken sei noch, dass mv unter FreeBSD über Filesysteme hinweg extrem unperformant ist, Zitat aus der Manpage:
Code: 
     As the rename(2) call does not work across file systems, mv uses cp(1)
     and rm(1) to accomplish the move.  The effect is equivalent to:

           rm -f destination_path && \
           cp -pRP source_file destination && \
           rm -rf source_file
Das war mir bisher in dieser Form nicht bewusst, daher nochmals sorry :(


BTW:
Kam zufällig per Google vorbei, daher untrusted Source:
http://0x3b.com/projects/deldir ist mit sehr grosser Vorsicht zu geniessen, müsste aber wirklich schneller als find+xargs+rm sein.
 
You must log in or register to reply here.
Back
Top