hallo,
habe auf einer festplatte ext3 filesystem laufen (ide-platte)
in manchen ordnern sind dort bis zu 70.000 files drin..alle ziemlich klein.
auf der konsole wird alles sehr schnell verarbeitet...aber i m grafischen modus (kde) ist es in letzter zeit ziemlich träge...braucht lange, bis es alle files indiziert hat.
warum das jetzt so ist..keine ahnung. vor einer woche gings noch problemlos (auch mit den vielen dateien im graqfischen modus)
die festplatte ist zu 30 prozent belegt.
gibts da eine obergrenze für die anzahl von files in foldern bei ext3?
hat da irgendwer erfahrung mit ext3 und vielen files....wo man zur fehlerbehebung ansetzen könnte...oder gibt es irgendwelche optionen, die ich einstellen könnte um das ganze performanter zu machen?
ps: windows hängt sich überhaupt beim öffnen auf...also die datenanzahl ist schon eher gross...anderes filesystem??
wie gesagt..auf der konsole is okay...grafisch nicht
kennt jemand das problem?
anregungen werden gerne entgegengenommen...
Linux 15.036 Themen, 107.107 Beiträge
Hallo ghartl1,
versuche es einmal mit dem Paket "bleachbit". Ist eine Art Reiniger für tmp-Dateien, cookies etc.
Verwende den Reiniger seit Jahren in der admin und user - Version ohne Schwierigkeiten.
MfG.
violetta
Viele Dateien machen das System eigentlich nicht langsam. Mehr als unterstützt werden, kannst du gar nicht anlegen, wenn die maximale Anzahl erreicht ist, ist einfach Schluss mit Schreibzugriffen. Die maximale Anzahl von Inodes (was auch die maximale Anzahl Dateien ist) kannst du ausrechnen, Wikipedia kennt die Formel.
Da in der Konsole alles zu funktionieren scheint, dürfte es sich eher um ein KDE-verursachtes Problem handeln.
Als Versuch kannst du trotzdem die Indizierung von einer Tabelle auf B-Trees umstellen. Ob das viel bringt, kann ich nicht sagen, ich vermute eher nicht. Gemacht wird das mit tune2fs und der Befehl (ungetestet!!!) dürfte folgendermassen lauten: tune2fs -O dir_index /dev/sdXY (sdXY halt durch das passende Devicefile ersetzen).
Gibt es nicht auch noch eine maximale Anzahl von Verzeichniseinträgen (also Dateien und anderen Verzeichnissen die direkt innerhalb eine anderen Verzeichnisses liegen)?
Die Umstellung der Verzeichnisindizes wirkt sich AFAIR erst mal nur auf neu angelegte Verzeichnisse aus, bestehende Datenstrukturen bleiben zunächst unverändert.
Ansonsten: Ich habe ein ext3 Dateisystem mit >70 Mio (bei der letzten Prüfung) Dateisystemobjekten. Das macht sich bei umfangreichen Operationen geringfügig bemerkbar, aber auch nicht mehr. Das beschriebene Phänomen hört sich für mich eher nach dem Versuch an Dateitypen zu ermitteln und Vorschaubilder zu erzeugen oder Ähnliches...
Gruß
Borlander
Ja, die gibt es. In der Kernel-Doku zu ext2 (somit auch gültig für ext3) steht dazu:
There is an upper limit of 32000 subdirectories in a single directory.
Und gleich dazu finden sich auch Angaben zur maximalen Anzahl Dateien. Tatsächlich wird ab 10'000 Dateien die Verwendung von Hashed Indices empfohlen. Das absolute Limit scheint ghartl aber noch lange nicht zu erreichen:
There is a "soft" upper limit of about 10-15k files in a single directory
with the current linear linked-list directory implementation. This limit
stems from performance problems when creating and deleting (and also
finding) files in such large directories. Using a hashed directory index
(under development) allows 100k-1M+ files in a single directory without
performance problems (although RAM size becomes an issue at this point).
The (meaningless) absolute upper limit of files in a single directory
(imposed by the file size, the realistic limit is obviously much less)
is over 130 trillion files. It would be higher except there are not
enough 4-character names to make up unique directory entries, so they
have to be 8 character filenames, even then we are fairly close to
running out of unique filenames.
Die Umstellung der Verzeichnisindizes wirkt sich AFAIR erst mal nur auf neu angelegte Verzeichnisse aus, bestehende Datenstrukturen bleiben zunächst unverändert.
mmmmh, gut zu wissen. Klingt irgendwie auch logisch, da sonst die Umstellung ein ziemlicher Rechen- und I/O-Aufwand wäre. In dem Fall müsste ghartl also die Files zusätzlich noch in ein neu angelegtes Verzeichnis verschieben...
danke the_mic..
aber das is mir doch zu heikel mit dem tune2fs befehl :-))
Gibt es einen Grund, nicht auf ext4 upzugraden?
Ja, ext4 ist für keine Produktivumgebung freigegeben.
HTH
Wer sagt das?
Du selber..
Gruss
Und auf welches Kernel-Release hat sich meine damalige Aussage bezogen? In den aktuellen Releases ist ext4 als stabil markiert und verhält sich auch genau so. Das ist allerdings erst seit ca 2.6.30 oder .31 der Fall. Bei vorherigen Versionen würde ich es definitiv noch nicht produktiv einsetzen.
Doch!
Mach mal folgendes:
Öffne eine Konsole und gib "glxgears" ein.
Dann sollten sich auf dem Bildschirm 3 Zahnräder ineinander drehen.
Das Ganze sollte ruckelfrei und flüssig vonstatten gehen.
Ruckelt es, dann hast Du Dir die Graphik zerschossen.
Wenn Du OpenSuse 11.x verwendest kannst Du folgendes machen:
Den Rechner komplett neu booten mit dem Parameter "Runlevel 3"
Dann "sax2 -a" als root aufrufen.
Das generiert eine neue Graphik.
Bei anderen Distries hilft evtl. ein Umbenennen der /etc/X11/xorg.conf und anschließend ein erneuter Setup für die Graphik.
gute idee systemcrasher...werds mal ausprobieren..