nicht angemeldet
Dateisysteme, wieviele Dateien passen rein?
Hello,
mal eine theoretische Frage:
Wieviele Dateien bekommt man in ein Dateisystem?
Gibts irgendwo eine fertige Formel oder muss ich die erst selbst entwickeln?
Filesystemtyp z.B.:
- FAT32
- ext2
- reiserfs
- ...
Daraus resultierende min. Blockgröße
Daraus resultiernder Overhead pro
- Datei
- Block
- Directory
- Seite
- ...
Sonstige Beschränkungen z.B. bei FAT die maximale Anzahl von Einträgen im Root-Table
Was macht das System langsam?
- Mehr Directoriies
- Mehr Files pro Directory
- viele gleichartige Namen
- lange Namen
- ...
Wie groß sind die Verluste, bzw wie kann man sie klein halten?
- Differnez zwischen Blpck- und effektiver Dateigröße
Na usw.
Was müsste man denn noch berücksichtigen?
Hat es z.B. schonmal ausprobiert, seinen Linuxhost mit Dateien von ca. 2-5kB Größe vollzunuddeln?
Bilderverzeichnisse sind ja im Prinzip das gleiche...
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
-
Hello,
viele
Danke, das hilft mir weiter ;-)
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hallo,
viele
hehe, du warst schneller. ;)
cu,
ziegenmelker-
Hello,
viele
hehe, du warst schneller. ;)
Haben wir denn heute den ersten April? Ich dachte, es wäre der 14. Mai 2005
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
-
-
Hallo Tom,
mal eine theoretische Frage:
[...hier standen ganz viele Fragen...]
was hast du denn bisher selbst unternommen um diese Fragen zu beantworten? Wo bist du nicht weitergekommen?
SCNR
ziegenmelker-
Hello,
was hast du denn bisher selbst unternommen um diese Fragen zu beantworten? Wo bist du nicht weitergekommen?
Ich habe die Fragen zusammengetragen.
Sind das alle, die ich berücksichtigen müsste, oder kennt Ihr für PC-Filesysteme noch andere Dinge, die man berücksichtigen müsste?
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hallo Tom,
Sind das alle, die ich berücksichtigen müsste, oder kennt Ihr für PC-Filesysteme noch andere Dinge, die man berücksichtigen müsste?
mal im Ernst, wofür denn überhaupt? Willst du ein Buch schreiben? Ist dir denn nicht klar daß deine Fragen so umfangreich sind, daß man sie hier imho nicht wirklich abhandeln kann?
Du weißt doch sicher einiges über Dateisysteme und solltest eigentlich auch die Suchmaschine deiner Wahl schon bemüht haben. Dann hast du auch sicher schon die Erfahrung gemacht, daß du diesbezüglich im Netz mit Informationen schier erschlagen wirst.
Ich weiß das, weil ich durch einen Festplattegau letztes Jahr auch angefangen habe mich intensiv mit der Datenganisation auf HDs zu beschäftigen.cu,
ziegenmelker-
Hello Ziegenmelker,
danke für Deine Ausführungen. Ich habe sie aufmerksam studiert und unter "P" abgelegt ;-)
Gelegentlich sollen in diesem Forum sogar Fachleute vorbeikommen, die sich mit verschiedenen Dingen (aus welchem Grunde auch immer) schon intensiv auseinandergesetzt haben. Ich warte dann mal auf einen dieser Kandidaten, wenn es Dir nichts ausmacht.
@CZ: Dein Posting liegt _nicht_ bei "P" ;-))
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hallo Tom,
danke für Deine Ausführungen. Ich habe sie aufmerksam studiert und unter "P" abgelegt ;-)
ich weiß leider nichts mit "P" anzufangen, aber du wirst mich hoffentlich nicht dumm sterben lassen. Es lag/liegt mir übrigens völlig fern dich irgendwie dumm anzumachen, ich hätte mir halt einfach gewünscht, daß du deine Fragen etwas präziser stellst, daß du es kannst, hast du ja weiter oben im Thread bewiesen.
Gelegentlich sollen in diesem Forum sogar Fachleute vorbeikommen, die sich mit verschiedenen Dingen (aus welchem Grunde auch immer) schon intensiv auseinandergesetzt haben. Ich warte dann mal auf einen dieser Kandidaten, wenn es Dir nichts ausmacht.
Jaja, mit ein bisschen Polemik kann ich schon umgehen ;-). CZ hat dir ja auch jetzt schon einige Anworten gegeben, die ich dir auch hätte geben können, bzw. hast du ja oben auch mal erklärt, was dir schon alles klar ist.
Noch eine Anmerkung von mir.
Ein Dateisystem, welches nicht auf eine beschränkte Anzahl von Datei/Verzeichnis -Tabellen, oder auf eine verkettete Liste derselben angewiesen ist, muß generell ein anderes System der schnellen Auffindbarkeit von Dateien bereitstellen. Da bieten sich Datenbanken mit schnellen Binärbaum-Indizes an (Netware?), die aber eben den Nachteil haben, daß das Aktualisieren der Indizes relativ viel Zeit in Anspruch nimmt.
Um hohe Leseperformance zu erreichen empfiehlt sich imho ein schneller Mehrkanal SCSI-Raid-Controller mit viel Cachè.cu,
ziegenmelker
-
-
-
-
-
Hi,
mal eine theoretische Frage:
Uh oh, gefääährlich! ;-)
Wieviele Dateien bekommt man in ein Dateisystem?
Soviele wie reinpassen.
Genau: es kommt auf das Dateisystem an.Die einzige theoretische Grenze ist das Verhältnis von Inhaltsverzeichnis, Dateigröße und Gesamtgröße der Festplatte.
Gegeben sei eine der heutigen Festplatten von 100 GB Größe. Theoretisch ließen sich dort also 100 Gigastück Dateien a ein Byte Größe lagern. Da Du die aber auch wiederfinden möchtest hast Du den Overhead eines Inhaltsverzeichnisses das Du auf der gleichen Platte speichern mußt. Die Namen im Inhaltsverzeichnis und somit die Namen der Dateien selber müssen groß genug sein jeder Datei einen individuellen Namen verpassen zu können. Mit einem 32 Bit langem Namen könntest Du also 4.294.967.296 Dateien benennen. Der nötige Platz zum Speichern betrüge dann (gesetzt ein Byte = 8 Bit) 17.179.869.184 Byte. Der Rest ist für Dich und Deine Dreisatz ;-)Soviel zur hier recht nutzlosen Theorie (nicht ganz nutzlos: ist für CDROM/DVD durchaus wichtig)
Gibts irgendwo eine fertige Formel oder muss ich die erst selbst entwickeln?
Nein, da mußt Du Dir überall die Datenzusammensammeln und dann selber rechnen. Das schwierigste ist dabei aber wirklich nur das Zusammensammeln, aber da hilft Google.
Was macht das System langsam?
- Mehr Directoriies
- Mehr Files pro Directory
- viele gleichartige Namen
- lange Namen
- ...Tja, das ist 'ne gute Frage. Theoretisch gibt es nirgendwo einen Unterschied (höchtens noch bei langen Namen, da dort das Parsen für's Hashing naturgemäß länger dauert und Stringparsen ist nunmal O(n), da beißt die Maus keinen Faden ab). Praktisch kommt es hier aber mal wieder auf's Dateisystem an.
Was müsste man denn noch berücksichtigen?
Journailing?
Hat es z.B. schonmal ausprobiert, seinen Linuxhost mit Dateien von ca. 2-5kB Größe vollzunuddeln?
Ich, mit ReiserFS 3.5 + normalem Journailing. Kein Problem, selbst mit einer Millionen Dateien a 10 Byte ergab es nur 10 Millionen Byte Besatz. Etwas ungünstiger sieht da der Overhead bei mittleren Dateigrößen (um die 50 kib) aus, aber nicht wesentlich. (ist auch in späteren Versionen optimiert)
ReiserFS hat dafür einen für diesen Zweck optimierten B++Tree geschrieben, der auch nicht ganz volle Blätter auffüllt.Bilderverzeichnisse sind ja im Prinzip das gleiche...
Hast Du aber kleine Bilder! ;-)
Du kannst bei einem Problem mit kleinen Dateien und nicht dafür vorgesehenem Dateisystem auch so arbeiten, wie es früher mit Icons geschah: einen ganzen Satz auf einen Streifen, nur einen Ausschnitt davon zeigen und bei Bedarf den Bildstreifen hoch&runter bzw nach links&rechts bewegen. Das geht auch mit einer Datei, in der ein Menge kleiner Dateien hintereinander drinsitzen (mbox etc). Bei unterschiedlicher Größe der Dateien müßte ein Inhaltsverzeichnis geführt werden. Der Rest geht dann mit fseek(), ftell() usw. Es kosten ein wenig Geschwindigkeit, klar, aber bei Platzproblemen ist das die schnellste Variante.
so short
Christoph Zurnieden
-
Hello,
Die einzige theoretische Grenze ist das Verhältnis von Inhaltsverzeichnis, Dateigröße und Gesamtgröße der Festplatte.
Nun, ich gehe mal von FAT aus, weil ich das Ding fast noch auswendig hischreiben kann...
Da hat mal erstmal den FAT selber, mit wahlweise 8, 12, 16 oder 32 Bit pro Cluster
Den gibts doppelt
Darunter liegen noch Partinierungs- und Paramtertabellen, die lassen wir mal außen vor.Dann gibts pro Partition ein statisches Root-Verzeichnis, dass 32 Bit pro Zeile und 128, 266 oder 512 Zeilen enthält.
Dann kommt der NameSpace hinzu, um lange Dateinamen zu ermöglichen.
Dann kommen die Blöcke (Cluster), die ggf, zu Dateien zusammengefasst werden können.
Auf einem 16-Bit FAT sind maximal 65520 Einträge möglich, da jedem weiteren kein Startcluster mehr zugeordnet werden könnte. Die müssen sich nun aber die Directory-Einträge und die Datei-Einträge teilen.
... usw.
Das nur nochmal zur Verdeutlichung, was ich eigentlich will.
Bei anderen Filesystemen gelten andere Algorithmen.
Ich suche nun die kleinste gemeinsame Beschränkung, um die mindestens verfügbare Anzahl auf einer Festplatte der Größe XY abschätzen zu können.reiserfs scheint mir da im Moment das ausgeklügeltste Filesystem bezüglich Sparsamkeit und Geschwindigkeit zu sein. Ich kann mich allerdings auch täuschen.
Jedenfalls hat Mir Dein Posting schon mal weitere Ansätze gegeben. Danke.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hi,
Die einzige theoretische Grenze ist das Verhältnis von Inhaltsverzeichnis, Dateigröße und Gesamtgröße der Festplatte.
[FAT-Beschreibung]
Das nur nochmal zur Verdeutlichung, was ich eigentlich will.
Bei anderen Filesystemen gelten andere Algorithmen.Nein, das sind keine Algorithmen sondern Datenstrukturen. Ja, der Unterschied ist hier wichtig, Augenblick noch.
Ich suche nun die kleinste gemeinsame Beschränkung, um die mindestens verfügbare Anzahl auf einer Festplatte der Größe XY abschätzen zu können.
Das ist, auch wenn ich mich hier wiederhole, das von mir beschriebene theoretische Verhältnis von Inhaltsverzeichnis, Dateigröße und Gesamtgröße der Festplatte. Das ist, so leid es mir tut, der kleinste gemeinsame Nenner. Es gibt weit über hundert verschiedene Dateisysteme, da gilt es individuell zu entscheiden.
Ein ganzer Haufen fällt sowieso raus, da sie das OS nicht unterstützt, die Partition zu groß für das Dateisystem ist oder ähnliche Kleinigkeiten.
Meist geben die beteiligten OSe das zu benutzende Dateisystem eh vor, nur bei "Linux alleine" hast Du noch eine Qual der Wahl und vor der scheinst Du nun zu stehen wie es aussieht.reiserfs scheint mir da im Moment das ausgeklügeltste Filesystem bezüglich Sparsamkeit und Geschwindigkeit zu sein.
Es kommt drauf an. Wenn Du wirklich eine ganzen Arsch voll Minidateien hast, sprich Gigabyteweise Thumbnails von 2.5kib und des Journailings nicht unbedingt bedarfst (obwohl die normale Version des ReiserFS-Journailings flott genug für den normalen Gebrauch ist) dürfte ReiserFS eine kluge Wahl sein.
Vor allem, wenn Du kommerziellen Support benötigst solltest Du ReiserFS benutzen. Hans Reiser soll da sehr flexibel und vor allem schnell sein. Ich hatte aber leider noch nicht das Vergnügen ihn persönlich kennenzulernen.Ich kann mich allerdings auch täuschen.
Ja, das Risiko besteht natürlich immer ;-)
so short
Christoph Zurnieden
-
Hello,
Bei anderen Filesystemen gelten andere Algorithmen.
Nein, das sind keine Algorithmen sondern Datenstrukturen. Ja, der Unterschied ist hier wichtig, Augenblick noch.
Ertappt. Das waren mal wieder mehrere Denkschritte in einem Satz "output". Aufgrund der Datenstrukturen ergeben sich die Algorithmen zur Berechnung. So war's natürlich gemeint, aber das weißt Du ja :-)
Bleibt jetzt noch die Frage:
Welches von den allgemein bei Webhostern, die PHP und/oder PERL und/oder sogar Kompilate anbieten/zulassen, im Einsatz befindlichen Dateisystemen hat die beschi.....sten Eigenschaften bezüglich Anzahl von Einzeldateien (auch über Verzeichnisse verteilt) und Performance?
Es geht im nächsten Schritt um die Erstellung einer Applikation. Nun besteht die Frage, ob man eine eigene Abstaktionsschicht (Bigfile mit eigener Verwaltung) einführt, oder sich "ganz simpel" auf das Dateisystem stützen kann.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hi,
Bleibt jetzt noch die Frage:
Welches von den allgemein bei Webhostern, die PHP und/oder PERL und/oder sogar Kompilate anbieten/zulassen, im Einsatz befindlichen Dateisystemen hat die beschi.....sten Eigenschaften bezüglich Anzahl von Einzeldateien (auch über Verzeichnisse verteilt) und Performance?
Ich befürchte da spielen soviele Einzelfaktoren eine Rolle, das diese Frage ohne Vergleichstest einfach nicht zu beantworten ist.
Immerhin funktioniert das bei großen Hostern ja anders, falls Du nicht gerade eine eigene Kiste dort in's Rack geschoben hast. Da wird auf großen RAIDs gespeichert, vielleicht sogar verteilt, das genaue Dateisystem spielt da nur noch eine untergeordnete Rolle und wird eher nach Stabiltätsmaßstäben ausgewählt.
Du mußt also nur dran denken, Dir beim Speicherplatzanmieten auch gleich die maximale Dateienanzahl schriftlich(!) bestätigen zu lassen.Mietest Du jedoch gleich eine ganze Box mit eigenem Speicher an oder kannst sonst über das eingesetzte FS verfügen, würde ich im Linuxfalle ReiserFS-3.5 mit Standard-Journailing empfehlen, zumindest habe ich damit sehr gute Erfahrungen gemacht.
Es geht im nächsten Schritt um die Erstellung einer Applikation. Nun besteht die Frage, ob man eine eigene Abstaktionsschicht (Bigfile mit eigener Verwaltung) einführt, oder sich "ganz simpel" auf das Dateisystem stützen kann.
Prinzipiell sollte das Dateisystem vorzuziehen sein. Es gibt aber natürlich einige Situationen, die das nicht erlauben. Zum Beispiel ist bei den ganzen Speicherchips und -sticks das Dateisystem fast durch die Bank FAT. Da paßt manch ein /etc-Backup schon nicht mehr drauf, weil einfach zuviele Dateien drin sind. Da hilft dann nur Teeren&Federn sprich: tar&gzip. "Tar" ist so ein "Bigfile mit eigener Verwaltung" und kann auch direkt angesprochen werden, Du mußt da nicht erst mühsam etwas auspacken.
Mach' Dir also kein' Kopp, wie man hier in der Region sagt und nimm' einfach das günstigste Angebot.
so short
Christoph Zurnieden
-
-
-
-