[klawitter]

THX

[Internetkopfgeldjäger]

Zitat (klawitter: 05.03.2010, 10:30)

Ich habe die SSD von Besserwisser bekommen (160GB Intel Postville X25M G2) und nehme sie gerade in Betrieb.

Frage: Man sollte ja 10-20% des Speicherplatzes frei lassen. Ich denke bei einer so grossen Platte eher 10%. Was bedeuted das genau: nicht formatieren/unzugeordnet lassen oder einfach nicht mehr als zu 90% füllen?

Wenn es Dir um Fragmentierung auf dem Dateisystem geht, dann musst Du natürlich Platz auf dem Dateisystem lassen,
unformatierten Platz frei zu lassen nützt gegen Fragmentierung nichts.
Wear Levelling funktioniert allerdings unterhalb des Dateisystems.

[klawitter]

Fragmentierung an sich ist doch gar nicht möglich, da die räumliche Lage der Zellen doch keine Relevanz hat-?-

Das Argument zu Wearleveling leuchte mir auch nicht ganz ein: Ich hatte es in der Firmware verortet.

[chrismischler]

Einen Teil der SSD unpartitioniert zu lassen kann Sinn machen wenn man keine Möglichkeit hat die SSD zu trimmen aber ansonsten reicht es wenn man das Laufwerk einfach nicht komplett voll macht.

[Internetkopfgeldjäger]

Zitat (klawitter: 10.03.2010, 00:01)

Fragmentierung an sich ist doch gar nicht möglich, da die räumliche Lage der Zellen doch keine Relevanz hat-?-

Das Argument zu Wearleveling leuchte mir auch nicht ganz ein: Ich hatte es in der Firmware verortet.

Deswegen hat es für Wear Levelling auch keine Relevanz,
ob Du auf der SSD etwas unpartitioniert lässt.
Einen Vorteil bringt Dir unpartitionierter Platz auf der SSD jedenfalls nicht.
Es sei denn, Du wolltest Dir den unpartitionierten Platz für Linux oder ähnliches freihalten.

Einen mechanischen Lesekopf der hin und her flitzen muss,
den hat so eine SSD ja nun nicht,
daher wird es wohl weniger ausmachen, wenn das Windowsfilesystem fragmentiert.

[XiLeeN2004]

Zitat (chrismischler: 10.03.2010, 00:15)

Einen Teil der SSD unpartitioniert zu lassen kann Sinn machen wenn man keine Möglichkeit hat die SSD zu trimmen...

Und genau das kann ich mir nicht vorstellen... Denke nicht, dass der Controller in der Lage ist unpartitionierten Bereich zu nutzen. Es muss einen Bezug zum Dateisystem geben um feststellen zu können, welchen Status die Zelle überhaupt hat. Alternativ müsste der Controller parallel selbst eine Tabellen für den unpartitionierten Bereich führen und mit dem Dateisystem abgleichen. Halte ich für sehr unwahrscheinlich

Denke durchformatieren und halt nur 90% der Kapazität nutzen ist da der richtige Ansatz, zumal das den Trim-Befehl nicht aushebelt.

@Klawitter: Auf Computerbase findet man was über Blockdefragmentierung als Ursache für Leistungsverluste. Meiner Meinung nach ist es aber nur ein weitere Name für die grundsätzlich Problematik beim Beschreiben der SSD

[chrismischler]

Ich bin eigentlich ziemlich sicher, dass der Controller auch die Zellen im unpartitionierten Bereich nutzen kann. Wie das genau realisiert wird weiß ich aber nicht. Als die SSDs noch kein Trim beherschten wurde oft dazu geraten einen Teil der SSD unpartitioniert zu lassen.

[Internetkopfgeldjäger]

Nochmal kurz zum erläutern:
Wear Leveling sorgt dafür, dass die Speicherzellen sich nach Möglichkeit gleichmäßig abnutzen.
Das regelt der Controller in der SSD.
Die Firmware ist der Softwareteil für den Controller in der SSD.

Der Trim Befehl ist so ein Hype, weil angeblich
- so wird es zumindest in Online-Magazinen breitgetreten -
SDD langsamer werden würden, ohne diesen gehypten Trim Befehl.
Konnte da aber in einem Dreivierteljahr auf meiner SSD nichts dergleichen
wirklich festellen, im Gegenteil das Biest ist in dem Dreivierteljahr ganz ohne Trim Befehle
sogar noch schneller geworden,
ist mit gstat und mit diskinfo zu beobachten.

Beides hat nichts mit Dateisystemfragmentierung zu tun.
Die Dateisystemfragmentierung ist vor allem ein Windowsphänomen.
Auf anständigen Dateisystemen wurde diverse Vorsorge getroffen, damit
da nicht diese enthemmte Fragmentierung wie auf Windowsfilesystemen passiert.
UFS2 zum Beispiel reserviert per default 8 Prozent Platz auf dem Dateisystem,
quasi zum rangieren. Außerdem beherrscht es Block suballocation,
ein Feature, dass auch in Btrfs, ReiserFS, Reiser4 für die Speichereffizienz zu finden ist.

Beim Defragmentieren wird Platz zum rangieren auf dem Filesystem benötigt.
Sieht man zum Beispiel wenn man ein Windowsfilesystem, ganz egal ob FAT oder NTFS
proppevoll mit großen Dateien packt und dann die Defragmentierung startet.
Da wird man bei einer richtig vollen Partition dann sehen,
dass große Dateien nicht mehr rangiert werden können
und daher die Dateisystemdefragmentierung nicht mehr funktioniert.
Corsair rät übrigens von Defragmentierung auf SSDs ab.
Schätze mal um Schreibvorgänge zu ersparen und weil SDDs ohnehin sauschnell sind.

Edit:
Nachdem ich oben den Link von XiLeeN2004 zu Computerbase
gefolgt bin, ist mir nun auch klar, wo die Quelle dieser völlig überbewerteten
Trim Geschichte ist.
Dabei ist das doch halb so wild, denn das regelt die Garbage Collection des Cleaners
im SSD Controller. Machen SSD Controller, die was auf sich halten automatisch
im Hintergrund. Im Corsair Forum wurde das mal erläutert.
Im Computerbase Artikel wird es kurz angeschnitten,
ging aber wohl in dem ganzen Trim Hype unter:

Computerbase sagte:

Die zweite Möglichkeit besteht darin, dass der Controller diese Aufgabe automatisch übernimmt, sobald die SSD keine oder nur sehr wenig Aktivität hat

Hier gibt es noch ein Diagramm, wie die bei Wikipedia sich das in einer SSD in etwa vorstellen:

Dieser Beitrag wurde von Internetkopfgeldjäger bearbeitet: 10. März 2010 - 03:00

[XiLeeN2004]

Seine Daseinsberechtigung hat der Trim-Befehl schon... So erfährt der Controller unmittelbar und direkt vom OS, welche Blöcke als ungültig zu markieren sind (folglich für's Beschreiben vorbereitet werden können). Das kann der Controller sonst nicht wissen. Bei der automatischen Garbage Collection wird das nur über Umwege in Erfahrung gebracht. Dazu ein Auszug aus Wikipedia:

Zitat

Die Funktionsweise dieser automatischen Garbage Collection ist noch nicht geklärt, funktioniert aber wahrscheinlich über die Nutzung der Reservesektoren in einem Laufwerk. Das Problem liegt darin, dass ein Laufwerk nicht wissen kann, welche Sektoren zum Überschreiben freigestellte Daten beinhalten. Daher leitet es Anforderungen zum Überschreiben freigestellter Sektoren in die leeren Reserve-Sektoren um. Dies ist demzufolge schnell und verrät dem Controller, dass die ursprünglich angesteuerten Sektoren wirklich nicht mehr gebraucht werden. Diese löscht er nun im Leerlauf, wodurch sie frei werden. Diese Vorgehensweise behebt nicht die Ursache des Problems, großenteils aber dessen Auswirkungen.

Die automatische Garbage Collection scheint auch viel Leerlaufzeit zu benötigen, sofern ich diesen Artikel und Diagramme richtig verstehe.

[...but alive]

Zitat

Frage: Man sollte ja 10-20% des Speicherplatzes frei lassen. Ich denke bei einer so grossen Platte eher 10%. Was bedeuted das genau: nicht formatieren/unzugeordnet lassen oder einfach nicht mehr als zu 90% füllen?

SSDs mit Sandforce-Controller verwenden nicht ganz zufällig einen recht großen Teil der Zellen als Overhead. D.h. faktisch verfügst Du über 128GB Platz, aber Du kannst nur 100GB nutzen.

Ansonsten mal bei anandtech lesen..
http://www.anandtech...doc.aspx?i=3667

Zitat

SSDs are made up of millions of NAND flash cells. They can be written to in groups called pages (generally 4KB in size) but can only be erased in larger groups called blocks (generally 128 pages or 512KB). These stipulations are partially the source of many SSD performance issues.

The whole ordeal gets more complicated when you realize that an SSD has no way of knowing when a file is deleted. Until an address gets used again, the SSD has to keep track of every last bit of data that’s written to it. The ATA-TRIM instruction tilts the balance in favor of the SSD.

In a supported OS (e.g. Windows 7), whenever you permanently delete a file or format your drive, the addresses that are erased are sent along with the TRIM command to the SSD’s controller. The TRIM instruction tells the SSD that those locations don’t contain valid data and that it no longer has to track them.


Simplified version of how a SSD controller works. TRIM helps the SSD clean blocks and add them to the free block pool

Again, I won’t go into great detail here but TRIM addresses a major part of the performance degradation over time issue that plague all SSDs. A TRIM enabled drive running an OS with TRIM support will stay closer to its peak performance over time.

usw.

Dieser Beitrag wurde von ...but alive bearbeitet: 10. März 2010 - 07:04

[klawitter]

@ INKGJ
ich hatte mich zum Wearleveling in deinem Post verlesen, habe 'innerhalb' statt 'unterhalb' gelesen. Mit der im Raum stehenden Frage hat diese Funktion allerdings in anderem Zusammenhang tun. Deshalb leuchtet mir das Ziel deiner Ausführungen dazu nicht ganz ein(?).

Die Frage ist, ob Wearleveling nur partitionierte Zellen/Blocks berücksichtigt oder eben auch unpartitionierte. Da es dabei aber um den 'Abnutzungsausgleich' geht, ist das für die Geschwindigkeit der Palatte von indirekter Bedeutung. Dem Contoller selbst dürfte es ziemlich egal sein, wie er Daten sowie Partitionen räumlich verteilt, da sie im Gegensatz zur Scheibe keine reale physischen Lage haben.

Was er auf jeden Fall macht, ist so vilee Chips wie möglich anzusprechen, daher auch die steigende Schreibgeschwindigkeit bei grösseren Platten mit mehr Chips.

Nutzt Wearleveling immer alle Zellen, wäre die Frage partitioniert /unpartitioniert bereits beantwortet. Weisst du ob dem so ist?

Die Sache mit dem Trim ist alles andere als Hype, sondern die Impelmentierung und Vereinheitlichung der 'Garbage Collection' ins OS. Es mag ja sein, dass diverse Mickeymausseiten-Autoren die Funktion nicht durchschauen, aber den Leuten von Heise z.b. trau ich das schon durchaus zu

Diverse Firmwaretools dazu haben nicht einwandfrei oder zufriedenstellend funktioniert, teilweise musste man sie von Hand starten oder den Rechner lange im Leeerlauf lassen, damit die Leerung der Zellen erfolgt. Manchmal gab es sogar kontraproduktive Folgen (OCZ hatte da ein Problem mit imho der ersten Firmware mit GC(?)). Das Löschkomando wird nun direkt mit dem Befehl zu den Daten verschickt bzw. angelegt, was absolut Sinn macht. Denn die Frage, ob Daten noch im Dateiverzeichnis sind oder bereits rausgeflogen sind, kann der Controller der SSD für sich so erst mal nicht beantworten.
MIt Garbage-Collection muss er logischerweise gesondert nachfragen. Dieser Prozess entfällt durch Trim schon mal.
Allein das macht bereits Sinn.

Ich kann mir nur Vorstellen, dass Deine SSD über reichlich Overhead verfügt und dadurch (noch) nicht in die Verlegenheit kommt zu lahmen oder du bereits eine mit eigenständiger (und gut funktionierender) Garbage Collection hast. Die von dir genannten Dateisysteme könnten durch ihre sorgsame Struktur durchaus eine weiteren Teil dazu beitragen. Grob ist es das Gleiche wie Trim, hat nur einen anderen Namen, einen anderen Ort und etwas andere Funktionsprinzipien und ist letztlich die umständlichere Variante.

Die Frage bleibt im Raum stehen: Welchen Bereich nutzt Wearleveling aus und benötigt die SSD mit Trim noch den (temporären) Puffer, den sie mit Garbage-Collection noch braucht bzw. wann werden die Trim-Befehle ausgeführt?

[...but alive]

Intel-Nutzer der ersten Generation sind ebenfalls in den Arsch gekniffen, denn Intel hat TRIM nur per Firmware-Update nachgereicht - und zwar ausschließlich für G2 SSDs...

Das nennt man dann wohl "Early Adopter-Bonus"...

Das teuerste Stück Hardware im PC war mal die GPU - jetzt ist es die SSD - und dann gab es ja noch das Debakel mit dem gepfuschten Firmware-Update, das dir die SSD zerschossen hat

Dieser Beitrag wurde von ...but alive bearbeitet: 10. März 2010 - 11:36

[Leshrac]

Zitat (klawitter: 10.03.2010, 11:50)

Die Frage bleibt im Raum stehen: Welchen Bereich nutzt Wearleveling aus und benötigt die SSD mit Trim noch den (temporären) Puffer, den sie mit Garbage-Collection noch braucht bzw. wann werden die Trim-Befehle ausgeführt?

Wear leveling nutzt immer den gesamten NAND range, voellig egal ob es nun partitioniert ist oder nicht, egal welches FS. Das findet immer low level statt, waere sonst ja auch ziemlich sinnfrei.
Wie ich dir zuvor schon sagte ist das freilassen ein ueberbleibsel von frueher, als die SSDs noch keinen "surplus overhead" hatten. Der einzige sinn im nicht partitionieren ist dann, dass man die SSD nicht mal unabsichtlich komplett voll macht, rein eine sache des comforts. Mit den neuen spielt das aber eben keine rolle mehr, wie gesagt, ich habe es ausprobiert und konnte keinerlei fehler oder abfall der performance feststellen.

Zu trim sagt der link von ...but alive eigentlich alles.

Und warum IKG jetzt auf fragmentierung kommt ist mir ein raetsel, denn das spielt bei einer SSD absolut gar keine rolle mehr.
Aber ein bisschen BSD werbung muss wohl immer eingebaut sein

[Mr. Floppy]

Zitat

Die Frage bleibt im Raum stehen: Welchen Bereich nutzt Wearleveling aus und benötigt die SSD mit Trim noch den (temporären) Puffer, den sie mit Garbage-Collection noch braucht bzw. wann werden die Trim-Befehle ausgeführt?

Ich versuche mal mangels belastbarer Informationen logisch an die Sache zu gehen. Das Wearleveling wird sich mit großer Wahrscheinlichkeit über den gesamten zur Verfügung stehenden Bereich erstrecken. Alles andere macht einfach keinen Sinn. Der Controller weiß auch gar nicht, welcher Bereich partitioniert ist bzw. es kann ihm egal sein. Er gibt sich nach außen wie eine normale Festplatte mit Sektoren, Zylindern und dergleichen. Nach innen muß das aber irgendwie auf die Zellen abgebildet werden.

Beispiel:
Das OS kommt also daher und sagt, liebe SSD schreib mir mal an die Adresse A56 die und die Daten. Die SSD sagt ok und schreibt die Daten intern an die für den Controller geeignetste Stelle und merkt sich dann, daß die Daten, die das OS bei A56 vermutet in den Zellen Z234, Z1278 stehen.

Da es keinen direkten Bezug zwischen den Daten und dem Speicherort gibt, kann man auch nichts mit einer geschickten Partitionierung beeinflussen. Für den Controller ist nur interessant, ob sich in einer Zelle Daten befinden oder nicht. Und genau hier kommt TRIM ins Spiel. Ohne TRIM kriegt der Controller nicht mit, wenn Daten im Dateisystem gelöscht wurden. Im "Inhaltsverzeichnis" des Dateisystems wird die entsprechende Datei als gelöscht markiert bzw. deren Eintrag gelöscht. Die eigentlichen Daten belegen aber immer noch Zellen auf der SSD. Erst wenn das OS neue Daten an die gleiche Stelle schreiben will, merkt der Controller, daß diese implizit gelöscht wurden. Hier kann der Garbagecollector erst aktiv werden. Das dumme ist aber, daß die scheinbar belegten Zellen währenddessen nicht für andere Zwecke benutzt werden können. Der Worst Case sind nur teilweise belegte (aber eigentlich gelöschte) Zellen. Diese sorgen für Leistungseinbußen, weil der Inhalt vor dem Beschreiben erst (überflüssigerweise) gelesen und dann mit den neuen Daten zurückgeschrieben werden muß.

Der TRIM-Befehl schafft hier Abhilfe. Statt nur den Eintrag aus dem Inhaltsverzeichnis des Dateisystems zu löschen, wird dem Controller gleichzeitig mitgeteilt, an welcher Stelle sich die Daten befunden haben (im obigen Beispiel Adresse A56). Der Controller kann jetzt also in seine Lookuptable gucken und die entsprechenden Zellen als gelöscht markieren. Ganz so einfach ist es aber nicht, weil sich in einer Zelle noch andere Daten befinden können.

Ich habe hier schon mehrfach gelesen, daß der Controller als gelöscht markierte Zellen in einer ruhigen Minute tatsächlich löscht also mit Nullen überschreibt. Dem möchte ich widersprechen*. Gerade das soll TRIM doch überflüssig machen. Da Zellen sowieso immer komplett geschrieben werden müssen, kann ich mir das verschleißfördernde Löschen vorher doch sparen. Nur, wenn die Zelle nicht leer ist, muß ich die Daten vorher lesen, mit den neuen verknüpfen und kann sie dann neu schreiben. Der TRIM-Befehl spart also das zeitraubende Lesen vor dem Schreiben indem er die Anzahl freier Zellen erhöht bzw. verfügbar macht, die direkt beschrieben werden können.

Trotzdem kann es eine gute Idee sein Speicher frei zu lassen. So verhindert man nämlich, daß das Wearleveling einschreiten muß, weil immer die gleichen Zellen genutzt werden. Das ist ja die Idee vom Sandforce. Man läßt sich mehr Platz damit die einzelnen Zellen weniger oft beschrieben werden müssen und packt die Daten vorher, um das Datenvolumen insgesamt zu verkleinern. Nebenbei wird noch mit einer Art symbolischer Links gearbeitet, was vor allem bei vielen gleichartigen Daten Vorteile bringen kann.

EDIT:
*Nee, doch nicht, wie schnell man doch das Wissen aus 3 Jahren E-Technik vergessen kann

Dieser Beitrag wurde von Mr. Floppy bearbeitet: 10. März 2010 - 12:16

[klawitter]

@ Leshrac und Mr.Floppy

eben so hatte ich mir das auch schon zurechtgedacht, war aber über teils widersprüchliche oder nicht hinreichend belegte Aussagen im Web etwas unsicher geworden.

@ Mr.Floppy
interessenshalber: wenn der Controller qua Trim weiss, in Zelle/Block xy ist was drin, was weg kann, bleibt ihm die Abfrage die er per Garbage Collection durchführen muss erspart. Aber was passiert dann?
Wird dann doch erst beim (vorm) Schreibzugriff gelöscht?