Hi
Habe im Zustand der Umnachtung den totalen Mist fabriziert. Folgendes, ich wollte mein System sichern und hatte mir eine Firewireplatte besorgt. Auf der Platte fehlte ein Dateisystem was ja kein Problem ist, nur wenn man dann bei einem Verdreher im Hirn anstatt der Firewireplatte die Partition ( Raid0 ) die man sichern möchte formatiert, schaut man doof drein. Pikanterweise war ich bisher immer ein fanatischer Verfechter des meiner Meinung bis dahin schnellsten und sichersten Dateisystems XFS. Hätte ich das weniger sichere und vor allem langsamere EXT3 verwendet, würden mir aber jetzt mehrere Programme zur Verfügung stehen mit denen ich den Fehler rückgängig machen könnte. So habe ich XFS mit XFS überschrieben und so wie es jetzt ausschaut bleibt das jetzt auch so.
Hmm als gebranntes Kind mache ich mir jetzt so einige Überlegungen. Angenommen ich würde jetzt alle Gäste auf einer eigens mit EXT3 angelegten Partition anlegen, würde es dann eigendlich Sinn machen innerhalb den Gästen dann performante Dateisysteme wie NTFS, HPFS oder XFS für Windows, Mac oder Linux zu verwenden? Wie sind eure Erfahrungen?
grüsse Darko
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Oh weia und ne Frage zum Dateisystem
Was ist dir denn wichtig? Dass das Dateisystem schnell ist, dass es sicher ist oder dass du nach einem Fehler wie diesem trotzdem noch an deine Daten kommst?
Da du ein RAID0 verwendest tippe ich mal auf "schnell".
Nun wäre die frage zu klären, was denn ein "schnelles" Dateisystem ist, bzw welche Punkte dieses Dateisystem denn schnell machen.
In der Regel sind das doch zwei Punkte. Erstens soll möglichst schnell erkannt werden, wo Datenbruchstücke liegen, wenn sie gefordert werden. Hierbei ist also die eigentliche Lesegeschwindigkeit unerheblich, der eigentliche Aufbau bzw die Sortierung einer entsprechenden Tabelle entscheidet. Andererseits sollten natürlich Performancesteigernde Effekte von Datenträgern genutzt werden. Wenn Daten stark fragmentiert sind und der Lesekopf mehr Zeit mit springen als mit lesen verbringt, ist das natürlich unvorteilhaft.
Mehr fällt mir da auf anhieb wirklich nicht ein, was ein Dateisystem "schnell" machen könnte.
Andererseits stellt sich die Frage, was ein Dateisystem denn langsam macht. Hier zählen Verschlüsselung, Kompression, schon genannt die Fragmentierung und Journaling. Ohne Frage sind all diese Punkte je nach Anwendung durchaus sinnvoll, allerdings sind in der Regel genau das die Stellen, die ein Dateisystem langsam machen.
Bei etwas entfernterer Betrachtung komme ich also zu dem Schluss, dass ein schnelles Dateisystem eines ist, das den Datenträger an sich möglichst wenig bremst. Ob das nun durch Fragmentierung oder zusätzliche Dateioperationen ist.
Jetzt kommen wir zum Thema "Dateisystem im Dateisystem", sprich "arbeiten in Images".
Jeden Satz den ich schreibe müsste ich mit fünf andere kommentieren und eigentlich sollte ich Zeitgleich von fünf Richtungen rangehen, dass ich am Ende einheitlich bei dem rauskomme, was ich sagen will. Ich versuch s mal.
Für das Hostsystem ist die vmdk-Datei eine Binärdatei wie jede andere. Hierbei ist allerdings auch darauf zu achten, dass das Lokalitätsprinzip nicht untergraben wird.
Fall1:Gering fragmentierte vmdk-Datei auf dem physischen Datenträger und gering fragmentierte Daten innerhalb der vmdk-Datei.
Eine Operation innerhalb eimer vmdk-Datei geschieht in der Regel -- Lokalitätsprinzip -- in logischer Nähe der zeitlich benachbarten Operationen. Heißt beispielsweise werden häufig 100 Blöcke aus einer Datei gelesen, selten 100 Blöcke aus 100 Dateien.
Der Gast fordert nun 100 Blöcke an, die für ihn logisch benachbart sind. Das Gastbetriebssystem liest diese 100 Blöcke "in einem Zug", weil das Dateisystem des Gastes wenig fragmentiert ist.
Da auch das Dateisystem des Hosts wenig fragmentiert ist, kann auch dieses die 100 Blöcke "in einem Zug" lesen, da logisch innerhalb der vmdk-Datei physisch benachbart auf dem Datenträger liegen.
Fall2: Gering fragmentierte vmdk-Datei auf dem physischen Datenträger und hoch fragmentierte Daten innerhalb der vmdk-Datei.
Nach wie vor fordert der Gast nun 100 Blöcke an, die logisch am Anfang einer Datei liegen. Durch die hohe Fragmentierung muss nun allerdings innerhalb der vmdk-Datei an 100 Stellen gelesen werden. Das bedeutet, dass auch auf dem phsischen Datenträger an 100 Stellen gelesen werden muss. Viel Bewegung des Lesekopfes, geringe Geschwindigkeit.
Fall3: Hoch fragmentierte vmdk-Datei auf dem physischen Datenträger und gering fragmentierte Daten innerhalb der vmdk-Datei.
Die Anfrage von 100 Blöcken am Anfang einer Datei innerhalb des Gastes bleibt nach wie vor. Nun will das Gast-Dateisystem 100 Blöcke lesen, die innerhalb der vmdk-Datei "virtuel physisch" nahe beieinander liegen. Dadurch, dass die vmdk-Datei ordentlich verteilt auf der Festplatte liegt, muss der Lesekopf aber trotzdem hin und her springen. Was im Gast beieinander liegt, liegt auf dem Host trotzdem getrennt. Wieder ist hier mit deutlichen Geschwindigkeitseinbußen zu rechnen.
Fall4: Sowohl die vmdk-Datei auf dem physischen Datenträger als auch die Daten innerhalb der vmdk-Datei sind sehr stark fragmentiert. Hört sich schlimm an, ist aber nur geringfügig schlimmer als 2 und 3.
Die 100 Blöcke am Anfang einer Datei bleiben, logisch beieinanderliegend, Lokalitätsprinzip und so. Der Gast muss nun innerhalb der vmdk-Datei stark wühlen, 100 Sprünge durchführen. Heißt der Host kriegt keinen Leseauftrag "gib mir 100 Blöcke ab x" sondern 100 einzelne "gib mir Block Nummer x". Also muss auch die vmdk-Datei an 100 Stellen auf dem Datenträger gelesen werden.
Es ist also sehr darauf zu achten, dass sowohl die Daten innerhalb der vmdk-Datei wenig fragmentiert sind, als auch, dass dei vmdk-Datei wenig fragmentiert ist.
Bei Dateisystemen ohne Fragmentierung -- bzw bei welchen, die Fragmentierung ohnehin nicht wahrnehmen -- ist diese Aufschlüsselung auch nicht ganz unerheblich. Aufgrund des Lokalitätsprinzips geht "die Welt" davon aus, dass eine Anfrage von einem Block an Position x mit großer Wahrscheinlichkeit eine baldie Anfrage von einem Block an Position "x+1" nach sich zieht. Die Festplatte liest deshalb eine recht große Menge Daten auf einmal und hält sie im Cache. Auch wenn das Dateisystem ohnehin Cluster für Cluster anfragt, weil die Position des nächsten Clusters im vorhergehenden gespeichert ist, würde hohe Fragmentierung die Sache bremsen, weil damit der Cache übergangen würde.
Viel blah blah um nichts
. Der Konsenz ist eigentlich, dass jede Form von Fragmentierung ein System verlangsamt. Wer also nur dafür sorgt dass die vmdk-Datei physisch wenig fragmentiert sind oder nur dafür sorgt, dass die Daten innerhalb der vmdk-Datei wenig fragmentiert sind und das jeweils andere unbeachtet lässt ("ich mach wenigstens 50%, das reicht schon"-Gedanke) könnte meiner Ansicht nach gleich ganz auf solche Überlegungen verzichten.
Um nach soviel geschwalle am Thema vorbei auch mal was zum eigentlichen Problem zu sagen:
Ich würde nicht versuchen, formatierte Daten zu Retten, um sie dann zu nutzen. Soetwas ist im Regelfall zu teuer wenn man es richtig machen lassen will oder zu unsicher wenn man es selber macht. Ich arbeite ungern auf solchen Datenbeständen und suche dann stundenlang einen Fehler und find keinen, weil diese Form von Fehler ohne meine Wiederherstellung technisch garnicht auftreten kann und entsprechend nicht behandelt wird. Folglich wäre auch das für mich kein Punkt für oder gegen ein Dateisystem.
Da du ein RAID0 verwendest tippe ich mal auf "schnell".
Nun wäre die frage zu klären, was denn ein "schnelles" Dateisystem ist, bzw welche Punkte dieses Dateisystem denn schnell machen.
In der Regel sind das doch zwei Punkte. Erstens soll möglichst schnell erkannt werden, wo Datenbruchstücke liegen, wenn sie gefordert werden. Hierbei ist also die eigentliche Lesegeschwindigkeit unerheblich, der eigentliche Aufbau bzw die Sortierung einer entsprechenden Tabelle entscheidet. Andererseits sollten natürlich Performancesteigernde Effekte von Datenträgern genutzt werden. Wenn Daten stark fragmentiert sind und der Lesekopf mehr Zeit mit springen als mit lesen verbringt, ist das natürlich unvorteilhaft.
Mehr fällt mir da auf anhieb wirklich nicht ein, was ein Dateisystem "schnell" machen könnte.
Andererseits stellt sich die Frage, was ein Dateisystem denn langsam macht. Hier zählen Verschlüsselung, Kompression, schon genannt die Fragmentierung und Journaling. Ohne Frage sind all diese Punkte je nach Anwendung durchaus sinnvoll, allerdings sind in der Regel genau das die Stellen, die ein Dateisystem langsam machen.
Bei etwas entfernterer Betrachtung komme ich also zu dem Schluss, dass ein schnelles Dateisystem eines ist, das den Datenträger an sich möglichst wenig bremst. Ob das nun durch Fragmentierung oder zusätzliche Dateioperationen ist.
Jetzt kommen wir zum Thema "Dateisystem im Dateisystem", sprich "arbeiten in Images".
Jeden Satz den ich schreibe müsste ich mit fünf andere kommentieren und eigentlich sollte ich Zeitgleich von fünf Richtungen rangehen, dass ich am Ende einheitlich bei dem rauskomme, was ich sagen will. Ich versuch s mal.
Für das Hostsystem ist die vmdk-Datei eine Binärdatei wie jede andere. Hierbei ist allerdings auch darauf zu achten, dass das Lokalitätsprinzip nicht untergraben wird.
Fall1:Gering fragmentierte vmdk-Datei auf dem physischen Datenträger und gering fragmentierte Daten innerhalb der vmdk-Datei.
Eine Operation innerhalb eimer vmdk-Datei geschieht in der Regel -- Lokalitätsprinzip -- in logischer Nähe der zeitlich benachbarten Operationen. Heißt beispielsweise werden häufig 100 Blöcke aus einer Datei gelesen, selten 100 Blöcke aus 100 Dateien.
Der Gast fordert nun 100 Blöcke an, die für ihn logisch benachbart sind. Das Gastbetriebssystem liest diese 100 Blöcke "in einem Zug", weil das Dateisystem des Gastes wenig fragmentiert ist.
Da auch das Dateisystem des Hosts wenig fragmentiert ist, kann auch dieses die 100 Blöcke "in einem Zug" lesen, da logisch innerhalb der vmdk-Datei physisch benachbart auf dem Datenträger liegen.
Fall2: Gering fragmentierte vmdk-Datei auf dem physischen Datenträger und hoch fragmentierte Daten innerhalb der vmdk-Datei.
Nach wie vor fordert der Gast nun 100 Blöcke an, die logisch am Anfang einer Datei liegen. Durch die hohe Fragmentierung muss nun allerdings innerhalb der vmdk-Datei an 100 Stellen gelesen werden. Das bedeutet, dass auch auf dem phsischen Datenträger an 100 Stellen gelesen werden muss. Viel Bewegung des Lesekopfes, geringe Geschwindigkeit.
Fall3: Hoch fragmentierte vmdk-Datei auf dem physischen Datenträger und gering fragmentierte Daten innerhalb der vmdk-Datei.
Die Anfrage von 100 Blöcken am Anfang einer Datei innerhalb des Gastes bleibt nach wie vor. Nun will das Gast-Dateisystem 100 Blöcke lesen, die innerhalb der vmdk-Datei "virtuel physisch" nahe beieinander liegen. Dadurch, dass die vmdk-Datei ordentlich verteilt auf der Festplatte liegt, muss der Lesekopf aber trotzdem hin und her springen. Was im Gast beieinander liegt, liegt auf dem Host trotzdem getrennt. Wieder ist hier mit deutlichen Geschwindigkeitseinbußen zu rechnen.
Fall4: Sowohl die vmdk-Datei auf dem physischen Datenträger als auch die Daten innerhalb der vmdk-Datei sind sehr stark fragmentiert. Hört sich schlimm an, ist aber nur geringfügig schlimmer als 2 und 3.
Die 100 Blöcke am Anfang einer Datei bleiben, logisch beieinanderliegend, Lokalitätsprinzip und so. Der Gast muss nun innerhalb der vmdk-Datei stark wühlen, 100 Sprünge durchführen. Heißt der Host kriegt keinen Leseauftrag "gib mir 100 Blöcke ab x" sondern 100 einzelne "gib mir Block Nummer x". Also muss auch die vmdk-Datei an 100 Stellen auf dem Datenträger gelesen werden.
Es ist also sehr darauf zu achten, dass sowohl die Daten innerhalb der vmdk-Datei wenig fragmentiert sind, als auch, dass dei vmdk-Datei wenig fragmentiert ist.
Bei Dateisystemen ohne Fragmentierung -- bzw bei welchen, die Fragmentierung ohnehin nicht wahrnehmen -- ist diese Aufschlüsselung auch nicht ganz unerheblich. Aufgrund des Lokalitätsprinzips geht "die Welt" davon aus, dass eine Anfrage von einem Block an Position x mit großer Wahrscheinlichkeit eine baldie Anfrage von einem Block an Position "x+1" nach sich zieht. Die Festplatte liest deshalb eine recht große Menge Daten auf einmal und hält sie im Cache. Auch wenn das Dateisystem ohnehin Cluster für Cluster anfragt, weil die Position des nächsten Clusters im vorhergehenden gespeichert ist, würde hohe Fragmentierung die Sache bremsen, weil damit der Cache übergangen würde.
Viel blah blah um nichts
. Der Konsenz ist eigentlich, dass jede Form von Fragmentierung ein System verlangsamt. Wer also nur dafür sorgt dass die vmdk-Datei physisch wenig fragmentiert sind oder nur dafür sorgt, dass die Daten innerhalb der vmdk-Datei wenig fragmentiert sind und das jeweils andere unbeachtet lässt ("ich mach wenigstens 50%, das reicht schon"-Gedanke) könnte meiner Ansicht nach gleich ganz auf solche Überlegungen verzichten.
Um nach soviel geschwalle am Thema vorbei auch mal was zum eigentlichen Problem zu sagen:
Ich würde nicht versuchen, formatierte Daten zu Retten, um sie dann zu nutzen. Soetwas ist im Regelfall zu teuer wenn man es richtig machen lassen will oder zu unsicher wenn man es selber macht. Ich arbeite ungern auf solchen Datenbeständen und suche dann stundenlang einen Fehler und find keinen, weil diese Form von Fehler ohne meine Wiederherstellung technisch garnicht auftreten kann und entsprechend nicht behandelt wird. Folglich wäre auch das für mich kein Punkt für oder gegen ein Dateisystem.
Zurück zu „VMserver 1 und GSX“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste