defragmentiert ihr hin und wieder? (win7)

[Der Martin]

Hallo,

bei SSDs entsteht aber auch kein Nachteil durch Fragmentierung, weil der Zugriff auf jeden Sektor ungefähr gleich schnell ist - egal ob's direkt der nächste ist oder einer am anderen Ende des Chips.
Diese Aussagen kann man so nicht stehen lassen. Beim Lesen entsteht kein Nachteil durch Fragmentierung

gut, das hatte ich vor allem gemeint. Bei üblicher Nutzung sind Lesezugriffe schließlich um ein Vielfaches häufiger als Schreibzugriffe.

die Schreibgeschwindikeit leidet aber durch Fragmentiertung.

Das ist mir neu - und so ganz leuchtet es mir auch nicht ein.

Das liegt daran, dass auf SSDs nicht (idealerweise) linear geschrieben werden sonder möglichst gleichmäßig über alle verfügbaren Zellen.

Ja, klar. Aber die Zellen ("Sektoren") werden doch einfach über ihre Speicheradresse angesprochen, und so ist doch jede Zelle (oder zumindest jeder Block) direkt adressierbar. Warum sollte sich da ein Unterschied ergeben? Denkst du daran, dass der Speicher auf mehrere Chips verteilt ist, die quasi-simultan adressiert werden können, und so ein höheres Tempo ermöglichen als sequentielle Zugriffe auf denselben Baustein?

Das Ziel ist es, bei allen Zellen eine möglichst gleichmäßige Verteilung zu erhalten - mit zunehmender (nennen wir es jetzt) Fragmentierung der Daten entsteht aber ein Ungleichgewicht und die Schreib-Performance leidet teilweise enorm.

Hmm. Den Zusammenhang erkenne ich noch nicht. Es sei denn, du meinst ... siehe oben.

Ein gebräuchliches Feature ist hier Wear-Leveling welches für eine gleichmäßige Beanspruchung der Zellen sorgt. Das erreicht einerseits eine höhere Performance und andererseits wird die Lebensdauer der SSDs dadurch erhöht.

Ist mir auch schon zu Ohren gekommen. Und da man von der Anwendungsebene aus sowieso keinen Zugriff auf diesen Mechanismus hat, bleibt die Zuordnung von Sektornummern zu physikalischen Speicheradressen doch quasi-zufällig. Statistisch ergibt sich damit weder eine Verbesserung, noch eine Verschlechterung.

So long,
 Martin