-

[Little Boozer]

-

 

[Holt]

Mir drängt sich der Verdacht auf, dass das Antergos Setup meine Windows Partition formatierte, aber wie kann das sein? Das Volumen wird doch garnicht angesprochen weil im BIOS die SATA Konfigurationen auf AHCI standen.

Das RAID Volumen nicht, aber die einzelnen Laufwerk wohl sicher noch.

Eine Installation mit Windows 7 auf der Plextor hat gezeigt, dass keine der beiden Samsung SSD's oder das Volumen an sich auftauchen solange das BIOS AHCI fährt.

Die beiden Samsung SSDs stehen dann aber wohl noch in der Datenträgerverwaltung. Es bleibt eben dabei, dass man vor Installationen immer alle unbeteiligten Platte wirklich abklemmen sollte. Man steckt ja nie so genau drinne was ddie Installer machen und wenn der auf der einen Samsung eine aktive Partition erkannt hat und deren Bootloader von Windows ersetzen wollte, dann hat er das wegen des RAID 0 auch noch auf ganz falsche LBAs geschrieben und damit vermutlich den Bootloader von Windows zerstört.

Du könntest allenfalls noch mal Win8 auf die Plextor installieren und dann versuchen das RAID noch mal zum Leben zu bekommen, sonst wüsste ich auch nichts. Da es aber auch unter Win7 nicht ging, würde ich meine Hoffnungen nicht zu hoch hängen.

 

[Geht dich nichts an]

Ich dachte SSDs aollte man nicht formatieren.

 

[Holt]

Wie willst Du denn eine SSD überhaupt nutzen, wenn Du da keine Partitionen anlegst und diese auch formatierst?

 

[Holt]

Das Defragmentieren schadet den SSD aber auch nicht, es kostet den einen oder anderen P/E Zyklus, aber davon haben die meist genug. Dafür bringt es die Dateien wieder in zusammenhängende Cluster, was lange und damit schnelle Zugriffe über viele LBAs ermöglicht. Vor allem werden die Lücken, also unbelegten LBAs wieder zu zusammen gefügt, was dann den Effekt der langen Zugriffe auch bei neu angelegte Dateien erlaubt. So gar unsinnig ist das Defragmentieren bei SSDs daher auch nicht, selbst wenn die langen Zugriffszeiten von HDDs beim Ansteuern der Position des nächsten Fragments weg fällt und die Daten intern sowieso ganz anders auf die Flashadressen gemappt sind als die LBAs von außen es zeigen.

 

[Holt]

Das haben wir schon diskutiert und ich gehe da nicht weiter drauf ein. Wer die Zusammenhänge kennt, also weiß welche Abläufe beim Lesen oder Schreiben einer Datei statt finden, wird die Argumentation nachvollziehen können und den anderen werde ich es nicht noch mal erklären, da man sich diese Informationen auch im Netz zusammen suchen kann. Schlüsselworte sind: Filesystem, Treiber, ATA Befehlssatz und Länge der Zugriffe auf die SSD.

 

[Holt]

Dann glaube es weiter, aber das SSD bei kurzen Zugriffen weniger hohen Transferraten erreichen als bei langen, sollte auch Dir bekannt sein, ein Vergleich der 4k und der seq. Werte bei AS-SSD oder die Ergebnisse von ATTO zeigen das ja auch. Das bei einem Zugriff mehr als ein LBA oder ein Cluster gelesen oder geschrieben wird, sollte auch nicht neu sein und ebenso wenig sollte die Erkenntnis überraschen, dass bei einem solche Zugriff nur ein LBA und x folgenden (maximal 2^16 bei ATA Befehlssatz) adressiert werden können. Das kann man im ATA Befehlssatz nachlesen.

Was ist Fragmentierung? Fragmentiert ist eine Datei, die nicht komplett in aufeinander folgenden Cluster abgelegt ist.

Weiß man dann noch, dass Windows natürlich immer nur maximal bis zum Ende der Datei oder des Fragmentes liest, weil die Daten der nachfolgenden Cluster / LBAs ja zu nicht interessieren, so dürfte der Effekt klar sein, denn es auf die Zugriffe hat, wenn es viele über weniger LBAs gibt statt weniger über viele LBAs. Liegt eine 80k lange Datei auf den Clustern 50ff reicht ein Zugriff über 80k um sie komplett zu lesen oder zu schreiben, liegt sie über 20 einzelne 4k Cluster verstreut, so muss jeder einzeln gelesen werden, es sind 20 Befehle über je 4k (8 LBAs) nötig um die Datei zu lesen.

Das ist bei SSDs und HDDs absolut das gleiche und der Unterschied ist nur, dass bei HDDs die jeweiligen Positionen auch noch angesteuert werden müssen, weil sie LBAs stur in CHS umrechnen und bei SSDs werden diese eben auch immer andere Flashadressen gemappt und Kraut und Rüben im Flash verteilt abgelegt. Auch fällt die Zugriffszeit ungleich geringer aus, weshalb eben die Fragmentierung praktisch längst nicht so ins Gewicht fällt, weil ja eben die Fragmente im Alltag auch selten so extrem kurz sind und bei etwas längeren Zugriffen steigt dann die Performance schon wieder deutlich an. Das ändert aber im Prinzip nichts, dass die Fragmentierung die Anzahl der Zugriffe erhöht und die das durchschnittlich pro Zugriffe übertragene Datenvolumen senkt, damit auch die erzielten Transferraten sobald eine bestimmte Zugriffslänge unterschritten wird.

Noch ausführlich stelle ich es aber nicht dar, diese Erklärung sollte reichen und wer es anders sieht,, kann ja mal darstellen, wieso dieser Effekt nicht eintreten kann.

 

[Holt]

Bei 4k_64 hat Du aber immer noch weniger als bei seq. Zugriffen, weil der Overhead ja größer ist, wenn pro Befehl nur 4k übertragen werden und wer sagt Dir, dass Windows die Fragmente dann auch parallel liest? Bei HDDs wäre das extrem unpraktisch und es müsste bei größeren Dateien ein gewaltiger Puffer vorhanden sein, um die Fragmente darin sortieren zu können, da sie bei aktivem NCQ ja in einer veränderten Reihenfolge eintreffen. Außerdem lesen Programme größere Dateien auch meist stückweise und nicht als Ganzes mit einem Befehl.

Auch wenn Du nicht überzeugt bis, dass Prinzip scheinst Du nun verstanden zu haben und natürlich ist der Effekt von Fragmentierung bei SSDs weitaus geringer als bei HDDs und betrifft immer nur die auch wirklich fragmentierten Dateien.

Und vergiss die interne Anordnung der Daten innerhalb der SSD, die hat mit dem Thema nichts zu tun! Die Leute tun die Fragmentierung bei SSDs immer nur aufgrund dieses einen Aspektes als nicht existent ab, sehen aber den Effekt des Filesystem auf die Länge der Zugriffe nicht. Der Controller und die Idle-GC können aber das darüber liegende Filesystem nicht beeinflussen, dazu müsste er das Filesystem selbst verwalten, was natürlich sinnvoll wäre, aber bisher nicht realisiert ist.

 

[Geht dich nichts an]

Was ist den das furn komischer Thread geworden...

 

[Holt]

Du hast mir leider nichts Neues erzählt.

Da gibt es nichts neues dazu zu sagen. Wie schon in Post #9 gesagt:"Wer die Zusammenhänge kennt, also weiß welche Abläufe beim Lesen oder Schreiben einer Datei statt finden, wird die Argumentation nachvollziehen können und den anderen werde ich es nicht noch mal erklären,"

Dass es einen Unterschied zwischen seq. und z.b. 4K gibt ist offensichtlich.

Schön das wir uns da wenigstens einig sind. Das ist doch schon ein erster Schritt.

Aber Deiner Herleitung kann ich nicht folgen.

Woran harkt es denn? Ich vermute Du hast keine Ahnung wie die Länge von Zugriffen zustande kommt. Das solltest Du aber im Netz recherchieren, da findest Du das, vor allem auf den Seiten von Microsoft (NSDN, Technet). Aber bei "No Thanks" in der Signatur darf ich das wohl nicht erwarten und wo das für Linux dokumentiert ist, kann ich Dir nicht sagen. Irgendwo wird sich das aber sicher finden, so unterschiedlich wird das da auch nicht ablaufen, das sind ja Grundlagen die für alle Betriebssystem gleich sind.

Ich vermute eher es liegt an der Art des Zugriffs an sich, nicht aber wie das Dateisystem möglicherweise fragmentiert ist.

Wie man auf eine SSD zugreifen kann, findest Du im ATA Befehlssatz, bei dem unterscheiden sich ja SSDs nicht von HDDs, das kommt ja nun erst mit NVMe. Mit dem solltest Du auch mal befassen, auch wenn ich die Fakten schon genannt habe, nämlich das mit einem Befehl eben bis zu 2^16 aufeinander folgende LBAs adressierbar sind.

Also alles beim Alten.

Nein, Du hast doch schon erste Fortschritte gemacht, es fehlt Dir im Puzzel nur noch die Frage, wann Zugriffe wie lang sein können und was Fragmentierung, also Aufteilung von Dateien über mehrere Fragmente damit zu tun hat.