› › ›

Linux 14.983 Themen, 106.385 Beiträge

Verfolgung starten Optionen

Ext3 langsam

ghartl1 / 13 Antworten / Flachansicht Nickles

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...

bei Antwort benachrichtigen
Hallo ghartl1, versuche es einmal mit dem Paket bleachbit . Ist eine Art ... violetta7388
Viele Dateien machen das System eigentlich nicht langsam. Mehr als ... the_mic
Gibt es nicht auch noch eine maximale Anzahl von Verzeichniseinträgen also ... Borlander
the_mic Borlander „Gibt es nicht auch noch eine maximale Anzahl von Verzeichniseinträgen also...“
Optionen
Gibt es nicht auch noch eine maximale Anzahl von Verzeichniseinträgen (also Dateien und anderen Verzeichnissen die direkt innerhalb eine anderen Verzeichnisses liegen)?
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...
cat /dev/brain > /dev/null
bei Antwort benachrichtigen
danke the_mic.. aber das is mir doch zu heikel mit dem tune2fs befehl :- ghartl1
Gibt es einen Grund, nicht auf ext4 upzugraden? cscherwinski
Ja, ext4 ist für keine Produktivumgebung freigegeben. HTH Unholy
Wer sagt das? the_mic
Du selber.. Gruss Unholy
Und auf welches Kernel-Release hat sich meine damalige Aussage bezogen? In ... the_mic
Doch! cscherwinski
Mach mal folgendes: Öffne eine Konsole und gib glxgears ein. Dann sollten ... Systemcrasher
gute idee systemcrasher...werds mal ausprobieren.. ghartl1