SSDs defragmentieren, macht das Sinn?

BLOS NICHT !!! das ist das schlimmste, was du den dinger antun 
kannst...nimm eine die trim unterstützt und gut

XP kann offenbar nicht. Aber da es nichts gibt, für das nicht irgendwer 
einen Hack gefunden hat, geht es eben irgendwie doch. Offenbar spaziert 
dann ein Daemon durch das Filesystem und TRIMt alle freien Blöcke:
http://www.myce.com/news/ocz-first-to-introduce-trim-for-ssd-drives-15771/

Damit eine SSD auch länger hält, defragmntiert sich sogar die Festplatte 
selber. Sie versucht möglichst über den ganzen Flash die Daten so zu 
verteilen, dass jede Flashzelle gleichviel genutzt wird.

Hallo,

das Defragmentieren verursacht doch nur einen einzigen Schreibzugriff je 
Zelle. Bei 100.000-facher garantierter Wiederbescheibbarkeit sollte das 
also kein Problem sein.

Stefan Helmert schrieb:

> das Defragmentieren verursacht doch nur einen einzigen Schreibzugriff je
> Zelle. Bei 100.000-facher garantierter Wiederbescheibbarkeit sollte das
> also kein Problem sein.

Einem NTFS Defragger habe ich mal bei der Arbeit zugesehen. Während 
DOS/FAT Defragger am Filesystem vorbei optimierten und damit auch 
zusammenpackten, analysierte dieser NTFS Defragger lediglich die 
bestehende Fragmentierung der Files und kopierte zu sehr fragmentierte 
solange mit normalen Betriebssystemmechanismen in der Landschaft herum, 
bis entweder das Ziel oder eine Grenze erreicht war. Da NTFS bei 
vorneweg gegebener Filegrösse ganz gut alloziert funktioniert das 
leidlich. Aber nicht selten sind vor allem bei grossen Files etliche 
Anläufe drin.

Dazu kommt, dass jede solche Aktion aus Konsistenzgründen synchron 
arbeiten muss. Alle Veränderungem am Filesystem, wie frei/belegte 
Blöcke, Filenodes, Dir-Einträge usw. werden ebenfalls mit jeder solchen 
Aktion geschrieben, manches pro Aktion mehrfach.

Ohne TRIM Funktion führt das insbesondere bei Defragging von grossen 
Files (z.B. Disk-Images aus Virtualisierung) noch dazu, dass aus Sicht 
der SSD das Filesystem stärker belegt erscheint als es tatsächlich ist. 
Das Wear-Levelling also mehr Arbeit hat als nötig, denn der von der SSD 
als frei bekannte Bereich ist dafür sehr wichtig.

@  Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik)

>sagen, wear levelling fraktioniert absichtlich. Ein Defrag-Programm

Fragmentiert.

>dagegen versucht alles am Anfang der Platte zu sammeln. Ich bin der
>Meinung, dass Defrag nicht nur wegen des Zugriffs ohne bewegliche Teile
>nichts nützt,

Da wäre ich vorsichtig. Flash kann man auch nur dann SCHNELL lesen, wenn 
man große, zusammenhängende Blöcke auf eine Rutsch liest. Wenn man aus 
verschiedenen Adressen die Blöcke/Sektoren holen muss, wird er auch 
langsamer.

> sondern sogar massiv dadurch schadet, dass das wear
>levelling konterkariert wird.

Nun ja, das ist halt so ein legacy Problem. Die normale Software weiss 
nix von wear leveling und kann damit bisweilen ziemlich dazwischen 
funken.
Ideal wäre ein von grund auf geschlossen entwickeltes Filesystem, 
welches direkt auf die speziellen Anforderungen von FLASH ausgelegt 
wäre. Ist aber aus Kompatibilitätsgründen so nicht machbar. Aber ich 
meine, die bestehenden Lösungen sind schon recht gut. Und sie werden 
besser.

MfG
Falk

Kleines wikipediazitat zum Thema gefällig:


Eine Defragmentierung ist aufgrund der marginalen Lese-Zugriffszeiten 
nicht nötig. In Bezug auf die Schreibleistung differieren die 
Herstellerangaben jedoch. So warnt OCZ die Nutzer seiner MLC-basierten 
Core-Serie vor dem Defragmentieren,[35] während MTron für seine 
SLC-basierten Produkte ein Defragmentieren sogar empfiehlt.[36]

Winfried J. schrieb:

> Eine Defragmentierung ist aufgrund der marginalen Lese-Zugriffszeiten
> nicht nötig. In Bezug auf die Schreibleistung differieren die
> Herstellerangaben jedoch. So warnt OCZ die Nutzer seiner MLC-basierten
> Core-Serie vor dem Defragmentieren,[35] während MTron für seine
> SLC-basierten Produkte ein Defragmentieren sogar empfiehlt.[36]

Das passt schon. Je nachdem was das Ziel der Defrag ist. Defrag nutzt 
ab, aber die Scheibleistung steigt. Da das Thema Abnutzung bei SLC Flash 
um den Faktor 10 weniger relevant ist lassen sich diese Aussagen mühelos 
in Einklang bringen.

Reinhard Kern schrieb:

> Wer sagt das? Ein Block braucht seine Zeit, egal wo, und für die
> Adressierung zwischen den Blöcken geht keine Zeit verloren

Das ist der Punkt wo ich mir nicht sicher bin. Es könnte schon einen 
Unterschied machen, ob für den gleichen Job einer oder 5 Blöcke 
angefasst werden müssen. Nur ist das verglichen mit einer Festplatte 
Klagen auf ziemlich hohem Niveau.

klugscheißer schrieb:

> wenn eine datei 1024 Bytes groß ist, und eine Zuodnungseinheit 256 Bytes
> hat, dann benötigt man eben 4 Speicheradresse. Ob die jetzt
> aufeinanderfolgen oder wild verteilt sind, spielt keine Rolle!

Die beiden Samsung SLC,MLC NAND-Flashes, deren Datasheet sich bei mir 
auf der Platte befinden, haben 2KB Blöcke. Intel SSDs verwenden 10 
parallele Kanäle, was demzufolge auf einen effektive Pagegrösse von 20KB 
rausläuft. Wenn das Filesystem die üblichen 4KB Blöcke verwendet, dann 
macht es möglicherweise schon einen Unterschied, ob pro 20KB Lesevorgang 
5 Flash-Pages beansprucht werden, oder nur eine.

Dazu kommt, dass die SSDs den Flash-Speicher nicht direkt und linear 
adressieren können, weil das Wear-Levelling ein gewisses Mass an 
Verwaltung, an Blockmapping mit sich bringt. Je kleiner der einzelne 
Request, desto grösser ist der Verwaltungsaufwand.

Das gleiche gilt insbesondere für das Betriebssystem, auch da ist neben 
der Transferrate die Anzahl Requests ein bedeutender Faktor in der 
I/O-Performance. Bei eher kleinen Requestgrössen (untere 2stellige KB) 
ist die Gesamtperformance erfahrungsgemäss hauptsächlich von der Anzahl 
Requests abhängig, weniger vom Datenvolumen.

Folglich kann ein sequentieller Lesezugriff auf eine stark fragmentierte 
Datei durch die notwendige Verteilung auf etliche kleine Requests sehr 
wohl deutlich abgebremst werden.

Reinhard Kern schrieb:
> Falk Brunner schrieb:
>> Da wäre ich vorsichtig. Flash kann man auch nur dann SCHNELL lesen, wenn
>> man große, zusammenhängende Blöcke auf eine Rutsch liest. Wenn man aus
>> verschiedenen Adressen die Blöcke/Sektoren holen muss, wird er auch
>> langsamer.
>
> Wer sagt das? Ein Block braucht seine Zeit, egal wo, und für die
> Adressierung zwischen den Blöcken geht keine Zeit verloren - es ist also
> egal, ob es der folgende Block ist oder einer am anderen Ende.
> Jedenfalls behaupte ich das jetzt mal so. Also Antworten bitte mit
> nachvollziehbarer Quellenangabe, sonst können Falk und ich ja würfeln.
>
> Gruss Reinhard



Hängt vom verwendeten Flash ab und wie der Controller und der restliche 
Aufbau sind...
Bsp.:
Numonyx, Hynix oder Toshiba (die anderen Hersteller können ihren Kram 
behalten, wenn sie Datenblättern nur noch mit NDAs rausrücken)
SLC large/medium
http://hynix.com/datasheet/pdf/flash/HY27UK08BGFM%20(Rev0.0).pdf
http://numonyx.com/Documents/Datasheets/NAND04G-B2D_NAND08G-BxC.pdf
http://www.semicon.toshiba.co.jp/docs/datasheet/en/Memory/TC58NVG2S3ETA00_en_datasheet_090709.pdf

Normaler Read:
- Address setup / command : 7 Bytes a 25/50 ns
- Busy (Datentransfer Speicher -> interner Cache): 25000 ns
- Datentransfer zum Controller: n * 25/50 ns

Cache-Read:
- Address setup / Command : 7 Bytes a 25/50 ns
- Busy: 25000 ns
- Datentransfer erste Page zum Controller n * 25/50 ns
- Busy: <3000 ns - 30000 ns
- Datentransfer zweite Page ...

Der Unterschied ist je nach Typ deutlich...

Ähnliche Optimierungen gibt es auch beim Schreiben

Äääähhhhh, Leute.....
Ich habe damals den Fred eröffnet (bin nun registrierter User)

Ich habe doch bloß eine kleine simple Frage gestellt weil (es tut mir 
echt leid gefragt zu haben wenn ich sehe was hier abgeht.)
Ich habe die Frage gestellt damit sich Menschen die (mit dieser neuen 
Technologie) mehr Erfahrung haben wie ich mir meine Frage beantworten da 
ich bisher verschiedene Statements gehört habe (Viele halt nur von 
vollpfosten die nur Compterbild und PCGH kennen).

Es tut mir nochmals vielmals leid eine Frage gestellt zu haben, wusste 
nicht das das heutzutage unhöflich ist und sich Menschen die es nicht 
nötig haben zu antworten sich dadurch beleidigt/angegriffen fühlen.
Ich werde es in Zukunft anstreben dumm zu sterben.....

>ist doch jetzt eigentlich eine ganz sachliche und informative
>Diskussion!?

Echt?
K!
Dann muss ich mich noch an den Umgangston hier gewöhnen ^^
Aber dann zieht euch warm an! :-)

Naja Linux verwendet ein anderes Dateisystem.
In der regel ext2 oder ext3, neuerdings ext4.

Ich habe mal gehört (das bedeutet das ich es nicht 100%ig sicher weiß)
das diese dateisysteme für Fragmentierung nicht so anfällig sein sollen 
wie Fat, Fat32 oder NTFS.

Berichtigt mich bitte wenn ich falsch liege.