geschwindigkeit von großen verzeichnissen

[stanglwirt]

Hi,
ist wohl so, daß ein Dateizugriff langsam wird, wenn sich in dem Verzeichnis viele Dateien befinden.

also z.b.
/user/1.txt
/user/2.txt

(mehrere tausend .txt dateien)

Wie sieht es mit der Performance bei folgender Konstellation aus:
/user/1/test.txt
/user/2/test.txt

(mehrere tausend unterverzeichnisse von /user worin sich jeweils nur wenige Dateien befinden.)

Ist das Problem mit dem langsamen Dateizugriff damit umgangen oder nicht? Wenn ich das richtig verstanden habe, wäre bei 2. Lösung lediglich der Zugriff auf Verzeichnis /user langsam.
Gibt es eine andere Lösung für das Problem bei vielen userspezifischen Dateien (keine Datenbank)?

cu

[Joe User]

Ist das Problem mit dem langsamen Dateizugriff damit umgangen oder nicht?

Nein.

Gibt es eine andere Lösung für das Problem bei vielen userspezifischen Dateien (keine Datenbank)?

Geeigneteres Filesystem (Reiser/XFS) verwenden.

[stanglwirt]

wie kann ich das denn ohne anderes dateisystem umgehen? solch eine gravierende änderung ist bei meinem server fast nicht möglich.

würde es etwas bringen das user-verzeichnis weiter aufzusplitten?
also z.b. /user/100/1/test.txt (user 1-100)
/user/200/201/test.txt (user 201-300)

cu

[encbladexp]

Gibt es eine andere Lösung für das Problem bei vielen userspezifischen Dateien (keine Datenbank)?

Mehr RAM kommt immer gut, dadurch kann der Kernel mehr Daten im Speicher behalten...

Welches Dateisystem ist den eigentlich drauf?

mfg Betz Stefan

[Joe User]

Eine Aufsplittung der Verzeichnisse/Dateien kann Dir etwas mehr Performance verschaffen, nur wird sich der Unterschied nur in Benchmarks wiederspiegeln, aber nicht in der Realität. Ohne den Wechsel des Filesystems bleibt Dir nur noch das Verlagern von /user auf eine andere/eigene Partition/Festplatte/RAMdisk, sofern Du dies nicht eh schon gemacht hast.

[eizo]

Bringt das eigentlich auch in einem Loopfile was? Also: / und Rest ext3, Loopfile (etwa das Mail-Verzeichnis) mit reiserfs

[encbladexp]

Bringt das eigentlich auch in einem Loopfile was? Also: / und Rest ext3, Loopfile (etwa das Mail-Verzeichnis) mit reiserfs

Das bringt eher nen negativen Effekt mit: Es wird noch langsamer... Den Das Loopfile liegt ja auf nem Dateisystem, also hast du (rein technisch gesehen) 2 Dateisystem übereinander... Mal abgesehen davon: Es ist nicht ratsam 2 Dateisystem übereinander zu stabeln, die beide Journaling unterstützen... Stichwort: Datenintegrität...

mfg Betz Stefan

[isotopp]

Hi,
ist wohl so, daß ein Dateizugriff langsam wird, wenn sich in dem Verzeichnis viele Dateien befinden.

also z.b.
/user/1.txt
/user/2.txt

(mehrere tausend .txt dateien)

In ext2/ext3 sind Verzeichnisse als lineare Listen organisiert: Jeder Verzeichniseintrag enthält einen Zeiger auf seinen Nachfolger. Das wird bei vielen Dateien pro Verzeichnis relativ schnell sehr langsam.

Deine Idee mit der Aufsplittung in Unterverzeichnisse hilft. Das ist auch das, was z.B. Squid in solchen Fällen macht. Beachte aber, das Verzeichnisdateien niemals schrumpfen. Auch nach der Aufsplittung wird /user also groß (und langsam) bleiben. Du mußt also ein neues /u anlegen, Deinen Kram von /user/xyz nach /u/x/y/z moven und dann /u nach /user umbenennen.

Moderne Dateisysteme wie reiserfs und xfs haben Verzeichnisse, die als Baumstrukturen organisiert sind. Dort wächst die Lookup-Time für ein Verzeichnis also nicht mehr linear, sondern logarithmisch. In diesen Systemen tritt das Problem nicht auf.

Durch die Verwendung eines Loopback-Devices stellt Du das verwendete Dateisystem um, und damit wird auch der schnelle Verzeichniszugriff verwendet - das unterliegende Dateisystem ist bei einem Loopback-Device weitgehend egal. Du handelst Dir jedoch den Overhead durch das Loopback ein. Der kann - je nach Anwendung und Situation - jedoch kleiner sein als der Verlust durch die langsamen Verzeichniszugriffe.

ext3 hat in neueren Versionen auch die Möglichkeit, einzelne Verzeichnisse als Bäume statt als lineare Listen zu organisieren, wenn ich mich recht erinnere. Ich habe damit jedoch noch nicht experimentiert und weiß also nicht, wie stabil das ist, was die Voraussetzungen sind, und ob das Geschwindigkeitsmäßig effektiv ist. Der Benchmark, an den ich mich erinnere, hat das damals ziemlich abgekanzelt.

[theton]

Ne absolute Notloesung waere auch einfach viel mehr RAM reinzubauen und die ganzen Dateien in einer entsprechend grossen RAMDisk zu halten. Kann man ja beim Booten einmalig in den RAM laden und beim Runterfahren sowie per Cron regelmaessig mit den Daten der Festplatte synchronisieren.

[Roger Wilco]

FYI: Auf madpenguin.org startet gerade eine Artikelserie zum Thema Dateisystem-Design, die u. a. die Unterschiede zwischen "modernen" FS (im Artikel XFS) und traditionellen/alten FS (am Beispiel von FFS) beschreibt. http://www.madpenguin.org/cms/html/67/6045.html

[isotopp]

FYI: Auf madpenguin.org startet gerade eine Artikelserie zum Thema Dateisystem-Design, die u. a. die Unterschiede zwischen "modernen" FS (im Artikel XFS) und traditionellen/alten FS (am Beispiel von FFS) beschreibt. http://www.madpenguin.org/cms/html/67/6045.html

http://kris.koehntopp.de/artikel/diplom ... 0000000000
http://kris.koehntopp.de/artikel/diplom ... 0000000000
http://kris.koehntopp.de/artikel/diplom ... 0000000000

Lang ist's her... :)

[isotopp]

FYI: Auf madpenguin.org startet gerade eine Artikelserie zum Thema Dateisystem-Design, die u. a. die Unterschiede zwischen "modernen" FS (im Artikel XFS) und traditionellen/alten FS (am Beispiel von FFS) beschreibt. http://www.madpenguin.org/cms/html/67/6045.html

Dort steht

So, what was the problem with the Berkeley file system? Simple. All the inode information was stored in the superblock. This works fine for small drives, but picture in your mind a large drive. This would mean that the read head would have to go to the beginning of the drive to read an inode, then to the data blocks to get the file data, then back to the inode section, then back to the data and so on. This is called thrashing and is about as inefficient as file systems get.

Das ist leider Bullshit. Natürlich passen nicht alle Metadaten in den Superblock. Stattdessen stehen beim sysv-Dateisystem (dem ffs-Vorläufer) alle Inodes vorne auf der Platte zwischen dem Superblock und den Datenblöcken. Deswegen kommt es bei sysv zu Trashing.

Beim Berkeles-ffs passiert das genau nicht, denn ffs führt das Konzept der Block Groups ein (die dann in Folge auch erklärt werden, ohne Block Groups genannt zu werden). Das angesprochene Mapping von Block Groups auf Cylinder hat man übrigens recht bald wieder aufgegben, und zwar spätestens als Festplatten mit Interleave 1 üblich wurden (Ich hatte noch Platten mit Interleave 5 und 2, aber das war so um 1989 rum :) )

Auf Seite 2 geht es dann nur wenig besser organisiert weiter... *seufz*