Werden Partitionsgrenzen beim Ablegen von Daten eingehalten?

[A&M]

Hallo Spezialisten,


bin gerade dabei, mich auf die Einrichtung eines 120GB-SSD für ein Netbook (Acer One 522) vorzubereiten.
Durch Literatur- und Internetstudium konnte ich das Wichtigste schon in Erfahrung bringen.
Außer einen Sachverhalt, der mir aber nicht unwesentlich erscheint:

Es gilt ja, dass Controller und Firmware des SSD die Speicherzellen selbständig addressieren und zur Ablage von Daten die bisher am wenigsten verwendeten Speicherzellen zuerst auswählen. Zusätzlich steht dann auch noch ein Reservebereich zur Verfügung, der mit seiner Größe in den Laufwerkseigenschaften gar nicht sichtbar ist.

Wie muss man sich jetzt aber eine mit einem Dateisystem formatierte Partition vorstellen, die kleiner ist als der gesamte, zur Verfügung stehende Speicherplatz?

A - Als genau abgegrenzen Bereich der physikalisch vorhandenen Speicherzellen pro Partition, plus Reservebereich (für evtl. defekte Speicherblöcke)
oder
B - Prinzipiell quer über alle Speicherzellen des Laufwerks, damit auch einen unpartitionierten Bereich mit eingeschlossen, plus Reserve

===

Da es in meinem Fall mehrere primäre Betriebssystem-Partitionen werden sollen, hätte das Auswirkung auf die Wahl der Partitionsgrößen:

A - Primär 24 + 24 + 24 + Erweitert ≈40 = ≈112 GB
B - Primär 5 + 7 + 12 + Erweitert ≈88 = ≈112 GB

(Die drei zu installierenden Betriebssysteme haben mit Allem typisch bis zu 3, 5 und 10 GB Gesamtgröße)

===

Der erste Fall wäre mir eigentlich lieber, so könnte man die Betriebssysteme besser frisch & sauber halten.
Aber - erstmal hören, was Ihr dazu sagt ...


A&M

 

[Ice-Lord]

Partitionen sind Speicher Bereiche von bis
Sektor von bis....

Und somit klar getrennt!

Die überzähligen Sektoren die du meinst sind Reserven
falls ein Sektor nicht mehr beschrieben werden kann
und wird dann automatisch verschoben dein OS merkt bis auf
den ersten Schreibfehler nix davon.

Man kann also mehrere Betriebssysteme installen ohne
das sich die Dateien physisch "nahe" kommen.
Aber bei MBR sind nur 4 primäre möglich!

Wie sich das bei SSDs verhält weiß ich ehrlich gesagt nicht.
Wird aber nicht soviel anders sein.

 

[Holt]

120GB? Dann hat die wohl einen Sandforce Controller und bei den ist das Freilassen eines Teils der Kapazität witzlos, denn der kann sowieso nur eine begrenzte Kapazität schnell beschreiben und geht dann in den Recovery Modus, in dem die Schreibrate abfällt und außerdem hat er bei entsprechender Komprimierbarkeit der Daten sowieso intern mehr freien Platz als andere SSDs.

Wenn Du die Partitionen wegen der verschiedenen Betriebssystem brauchst, dann lege sie einfach so an wie bei einer HDD und gut ist. Intern verwaltet der Controller die Daten selbst und legt sie sowieso total gemischt auf den Flashadressen ab, was ja auch nötig ist, damit über die parallelen Zugriffe Geschwindigkeit erzielt wird.

 

[blahblupp]

durch wear leveling und overprovisioning werden sich die Daten im Laufe der Zeit über die ganze SSD verteilen

die Einteilung in unterschiedliche Partitionen ist hier nur noch eine Formalität, nicht wie früher bei HDDs

 

[Ice-Lord]

durch wear leveling und overprovisioning werden sich die Daten im Laufe der Zeit über die ganze SSD verteilen

die Einteilung in unterschiedliche Partitionen ist hier nur noch eine Formalität, nicht wie früher bei HDDs

Ok das macht irgendwo sogar Sinn.
Bei den SSDs hat die Firmware anscheinend deutlich mehr zu sagen
als bei HDDs

Is wohl nötig um die Performance zu gewährleisten.

Ich denk mal es kommt sowieso nicht gerade oft
vor das man SSDs aufteilt.
Und sollange die Firmware noch weiß wo was is sollte
es auch keine Probleme geben

 

[Holt]

Die externen Adressen (LBAs) werden auch ständig andere interne Flashadressen gemappt. Das muss wegen dem Wear-Leveling schon mal so sein und auch, weil das Controller zwar eine Page lesen und schreiben kann, aber nur einen Block von vielen 100 Pages auf einmal gelöscht werden kann. Hätte man eine starre Zuordung wie es bei HDDs der Fall ist, so müsste beim Überschreiben einer Page in dem Block der ganze Block gelöscht werden. Dazu müssten erst alle anderen gültigen Daten gelesen und danch ebenfalls wieder geschrieben werden, was eine unterirdische Performance und eine gewaltige Write Amplification zur Folge hätte, also überhaupt nicht akzeptiertbar ist. Deshalb sind die Controller von SSDs ja auch viel komplexer als die von HDDs, die so ein Mapping nur für defekte Sektoren machen und sonst einfach die LBAs auf Kopf, Zyklinder und Sektor umrechnen und haben auch einen sehr viel größeren Einfluss auf die Performance.

 

[A&M]

Ja, es ist ein SandForce 1222. Die Platte ist eine SanDisk Ultra (SATA II) mit SanDisk MLC-NAND Speicher.
(demnächst steht dieselbe Prozedur auch mit einer Winkom SL-564 (SATA II / Indilinx Barefoot / Intel SLC-NAND) auf einem anderen Rechner an.

OK. Anscheinend muss man sich bei SSDs den Begriff "Partition" ganz anders vorstellen, was mir aber noch nicht so recht gelingt:

Z.B. wie der Controller die unterschiedlichen Dateisysteme (*) verwalten kann, wenn er Daten partitionsübergreifend speichert.
Und ob mein bisheriges Vorgehen (im Sinne von "frisch & sauber"), ab und zu mal eine Partition zu löschen, neu zu formatieren und wieder mit einem angelegten Image des Betriebssystems zu belegen dann noch sinnvoll sein kann.

*
Vorgesehen sind ein WinXP (NTFS), zwei Linux-Versionen (EXT3 oder 4) und wahrscheinlich auch FAT32 für eine gemeinsame Datenpartition.

Dachte eigentlich, dass teilbelegte Blöcke grundsätzlich gelesen, ergänzt und komplett neu geschrieben werden ... muss nochmal nachlesen.
Wie groß ist ein Block eigentlich? Diese Angabe konnte ich bisher nirgends finden.

Auf jeden Fall schon mal vielen Dank für Eure Antworten!

 

[Krik]

Ein Block hat die Standardgröße von 512 Bytes. Ausnahme sind die Festplatten 4k-Sektoren, da sind die Blöcke 4096 Bytes groß. Das hat insbesondere bei der Einführung dieser Platten zu enormen Problemen geführt, da die 512 Bytes/Block schon seit Jahrzehnten gelten und oftmals hardkodiert vorliegen. So einfach kann man an hardkodierten Dingen nichts ändern. Aufgrund dieses Quasistandards verwenden Dateisysteme ebenfalls Blockgrößen von 512 Bytes.


Eine Partition ist im Prinzip eine Speicherbereich, der von Sektor X bis Sektor Y reicht. Innerhalb dieser Partition wird ein Dateisystem angelegt. Das Dateisystem zerlegt Dateien in 512 Byte große Blöcke und verteilt sie auf der Partition. Nicht immer werden diese Blöcke in einer Reihe abgelegt, also ein Block ist hier, ein anderer da da und einer dort drüben. Das nennt man dann Fragmentierung.
Eine Partition wird verwendet, um große Datenmengen logisch voneinander zu trennen, so wie das Verzeichnisse und Dateien im Prinzip auch tun.

In der Hardwareebene ist das ähnlich gemacht. Der Controller stellt einen Speicherbereich von Sektor 0 bis Sektor X dem Betriebssystem zur Verfügung. In diesem kann irgendwo eine Partition angelegt werden usw.
Die vom Controller gemeldeten Sektoren sind aber nicht zwangsweise identisch zu den Sektoren, die in Hardware gegossen sind. Ist eine Speicherzelle defekt, merkt sich der Controller das und leitet den Datenverkehr dieser Speicherzeile zu einer anderen Reservezelle um. Mit steigenden Wear Leveling führt das zu imemr mehr umgeleiteten Speicherzellen.
Wenn man will, kann man das ebenfalls Fragmentierung nennen. Allerdings wird diese Fragmentierung nicht durch eine zu kleine Lücke zwischen zwei Dateien sondern zwischen zwei defekten Blöcken ausgelöst.

 

[Holt]

Anscheinend muss man sich bei SSDs den Begriff "Partition" ganz anders vorstellen, was mir aber noch nicht so recht gelingt:

Z.B. wie der Controller die unterschiedlichen Dateisysteme (*) verwalten kann, wenn er Daten partitionsübergreifend speichert.

Der Controller verwaltet keine Partitionen, sonst müsste er ja die verwendeten Filesysteme kennen. Der verwaltet einen Pool von Speicheradresse und mehr nicht. Die Aufteilung in Partitionen und die Verwaltung der Daten drdrin ist danach alleine eine Sache der Betriebssystem auf dem Rechner.

Und ob mein bisheriges Vorgehen (im Sinne von "frisch & sauber"), ab und zu mal eine Partition zu löschen, neu zu formatieren und wieder mit einem angelegten Image des Betriebssystems zu belegen dann noch sinnvoll sein kann.

Das kann auf der Ebene des Filesystem sinnvoll sein, weil dann die Verrwaltungsdaten wieder neue und geordnet sind. Im Sinne der Ablage der Daten auf dem Speichermedium ist das aber unsinnig, da diese dort sowieso komplett anders abgelegt sind als es nach außen erscheint.

Dachte eigentlich, dass teilbelegte Blöcke grundsätzlich gelesen, ergänzt und komplett neu geschrieben werden ... muss nochmal nachlesen.

Das wäre ja grausam wenn das so wäre. Der Controller schreibt die Daten in eine andere, freie Page, mappt den entsprechenden LBA auf die neue Flashadresse und markiert die alten Flashadresse als ungültig. Damit wird die dann beim nächsten Löschen des Block nicht mehr mit kopiert und je man Pages in einem Block ungültige Daten enthalten, umso früher wird der Block wieder zum Löschen ausgewählt.

Wählt man Blöcke aus, die noch viele gültige Daten enthalten, so ergibt das eine hohe Write Amplification und wählt man immer nur die Blöcke aus, in denen die wenigsten Pages noch gültige Daten enthalten, so funktioniert das Wear-Leveling nicht. Dann will man aber auch möglich auf allen Kanälen freie Blöcke haben, damit beim Schreiben seq. Daten diese auch gut verteilt werden und entsprechend schnell geschrieben und gelesen werden können. Es ist also ein Zielkonflikt vorhanden aus dem es viele mögliche Auswege gibt, die alle Vor- und Nachteile bieten. Deshalb ist die Sache ja auch so kompliziert und die Controller haben so einen enormen Einfluss auf die Performance, Lebensdauer, etc. der SSD.

Wie groß ist ein Block eigentlich? Diese Angabe konnte ich bisher nirgends finden.

Das hängt vom jeweiligen NAND ab. Üblich sind 4k oder 8k Pages und 512kB, 1MB oder sogar 2MB Blöcke, tendenz steigend.

 

[Krik]

SSDs verwenden keine 512-Bytes-Blöcke? Das wäre mir neu.

 

[Holt]

Als Blöcke bezeichnet man bei NANDs üblicherweise die kleineste löschbare Einheit. Das Du meinst ist die logische Sektorgröße, also wieviele Bytes über einen LBA adressiert werden und da sind SSD wie moderne HDDs mit Advanced Format (also physikalischen 4k Sektoren): Sie emulieren 512 Byte LBAs. Deshalb muss man bei beiden Laufwerksarten auch auf das korrekte Allignment der Partitionen achten!

Lies auch mal dies hier.

 

[Krik]

Gut, ok. Es sind also ebenfalls 4K-Platten. Ich bin immer davon ausgegangen, dass man das eigentlich nur bei großen (>2 TB) Festplatten verwendet.

 

[Holt]

Bei größeren Platten (>2TB) verwendet man die Emulation der 512Byte Sektoren gerade nicht, weil sonst der Adressraum nicht ausreicht. Die nutzbare Kapazität eines Laufwerks ist ja das Produkt aus der Anzahl der LBAs und deren Größe. Die LBA Adressierung ist auf 48Bit beschränkt, dann kannst Du ja mal ausrechnene, wie weit man bei 512Byte pro LBA kommt.

Die Emulation von 512Byte Sektoren gibt es auch nur, weil viele ältere PC Systeme (Controller und Programme) eben die 512Byte fest erwarten statt den Wert von der jeweiligen Platte zu lesen und daher nicht korrekt mit Laufwerken umgehen können, die einen andere Sektorgroße angeben.
Da die 2.5" SSD die 2TB Grenze noch nicht erreicht haben, adressieren die alle 512Byte pro LBA, emulieren also 512 Byte Sektoren. Der Griff Sektor ist überigens sehr unglücklich weil vieldeutig. Damit kann man die Größe der LBAs meinen, die der pyhsikalischen Sektoren einer HDD (was vor Andanved Format das gleiche war) oder die Clustergröße des Filesystems (heute bei NTFS i.d.R. 4k).

Das Advanced Format setzt sich übrigend unabhängig von der Kapazität der HDDs immer mehr durch, weil es etwa 10 bis 15% mehr Nutzkapazität erlaubt, da die Prüfsummen über 4k statt nur 512Byte gebildet werden. Das hat mehr mit dem Erscheinungsdatum der HDD als mit deren Kapazität zu tun. Die neuen Modelle haben inzwischen eigentlich alle Advanced Format.

 

[A&M]

Jo.

Mein Prozessor (es ist ein älterer Dual-Core, bestehend aus linker und rechter Gehirnhälfte, mit integriertem Massenspeicher, zur Zeit etwas stark fragmentiert) ist gerade noch ziemlich ausgelastet damit, das Ganze einigermaßen aufzunehmen.

Momentan wüßte ich nicht, was jetzt für oder gegen kleine oder große Partitionen spricht, wenn sie vom Controller (bis auf die Gesamtgröße der darin ablegbaren Daten wahrscheinlich) sowieso ignoriert werden.

Einen Vorteil könnte es aber noch haben: Da in WinXP die Unterstützung von TRIM wohl nicht nachrüstbar ist, könnte dann ein gestartetes Linux nicht ab und zu diese Aufgabe für die ganze Platte übernehmen? Kennzeichnet XP gelöschte Dateien so, dass Linux es sehen und TRIM ausführen kann?

 

[Holt]

Das Linux die XP Partition trimmt, kann ich mit eigentlich nicht vorstellen, zumal ja die Dateien darauf i.d.R. unter Windows XP gelöscht werden und wohl nur selten unter Linux.Somit weiß Linux aber garnicht, welche LBAs nun von den gelöschten Dateien belegt waren und daher getrimmt werden müssen.

Obendrein ist es fraglich, ob Linux überhaupt NTFS oder FAT Partitionen trimmt, das geht wohl nur für EXT4 Filesysteme und auch nur, wenn beim Mountent der sprechende Parameter (discard) abgegeben wurde.

Aber wie schon geschrieben: 120GB deuten stark auf eine SSD mit Sandforce und bei dem ist TRIM weniger bedeutend, da er die volle Schreibleistung sowieso nach dem erstemaligen Beschreiben der NAND Pages verliert und die dann auch noch mehr einbricht, wenn man größere Datenvolumen am Stück schreibt, egal ob die SSD nun leer und getrimmt war oder nicht.

 

[etheReal]

Momentan wüßte ich nicht, was jetzt für oder gegen kleine oder große Partitionen spricht, wenn sie vom Controller (bis auf die Gesamtgröße der darin ablegbaren Daten wahrscheinlich) sowieso ignoriert werden.

Eine Partition auf einer SSD ist eine Trennung auf der Ebene des Betriebssystems. Wenn du zwei Partitionen hast, dann kannst du eine davon formatieren, und die andere bleibt. Das ist der einzige Grund, aus dem man auf einer SSD mehrere Partitionen brauchen könnte: wenn man z.B. die Partition mit dem OS formatieren will, aber eine zweite Partition mit Programmen soll dabei nicht gelöscht werden.
Oder eben wenn man zwei verschiedene Betriebssysteme installieren will, dann braucht man natürlich auch getrennte Partitionen.

Ansonsten sind mehrere Partitionen auf SSD ziemlich überflüssig und führen schneller zu Platzproblemen, als die Verwendung von einer einzigen, großen Partition.

 

[A&M]

Vielen Dank an alle, die geantwortet haben - und insbesondere an Holt, der in vielen Threads sehr wertvolle Information bereithält.

Es fällt mir gar nicht leicht, das alles aufzunehmen - aber jetzt probiere ich das einfach mal aus, damit die zukünftigen Fragen nicht mehr ganz so theoretisch sind.

 

[Holt]

Gerne geschehen. Um noch mal die Frage des Themas zu beantworten:

1.) Auf der Ebene der Flashadressen: Nein und das ist nicht nur nicht schlimm sondern sogar gut so, denn nur durch die Verteilung der Daten über die NAND Dies kann eine hohe Geschwindigkeit erreicht werden, weil die Controllerkanäle wie ein RAID 0 parallel angesprochen werden. Das verwaltet der Controller alles intern und ist vollständig transparent für das System, man wird erfahrt also nicht, auf welchen Flashadressen welche Daten liegen.

2. ) Auf der Ebene des Filesystems bzw. der Logischen Adressen (LBAs): Natürlich. Das ist wie bei allen HDDs auch und nur wenn ein Fehler vorliegt, dann kommt es zu überlappenden Partitionen und die führen früher oder später zu Datenverlust, weil dann die Daten der einen Partition die das anderen überschreiben. Das sollte aber normal nicht passieren, wenn man die Partitionen sauber angelegt hat.