Xon2 schrieb:
So, ich kann das jetzt nochmal bestätigen: die win 7 backup Routine
Wieso Backup Routine? Die Backups haben damit nichts zu tun, es gibt um den Defragmentierdienst der seit Win 8 ein Optimierdienst für die Laufwerke ist. Er wurde wohl umbenannt, eben weil er ab Win 8 auch SSDs optimiert, während er sie vorher immer gleich komplett aus dem Zeitplan geworfen hat.
Xon2 schrieb:
Wie Holt schon sagte, scheint Hanselman es einfach fälschlich auch unter der win 7 Kategorie veröffentlich zu haben und sich zudem auch etwas ungenau ausgedrückt zu haben.
Eben, was er scheibst passt nur zu Win 8 und höher, nicht aber zu Win 7, da läuft es anderes.
burkm schrieb:
Warum sollte eine SSD überhaupt defragmentiert werden ?
Der Zugriff erfolgt über die Adressierung rein elektronisch und damit quasi instantan
Die Fragmentierung ist eine Sache des Filesystems und der Zugriffe, die hat mit dem Medium (ob HDD oder SSD) gar nichts zu tun! Die ATA Befehle erlauben einen LBA mit bis den zu 2^16 darauf folgenden mit einem Befehl zu adressieren, also bis zu 32MiB bei 512 Byte pro LBA. Schau Dir mal die Ergebnisse vom AS-SSD Benchmark an, dann siehst Du das bei kurzen Zugriffen wie den 4k (was auch die übliche Clustergröße bei NTFS ist) die Transferraten weit schlechter als die bei langen Zugriffen (seq.) sind. Für die maximalen Transferraten brauchen heutige SATA SSD mindestens so 256 bis 512k pro Befehl, PCIe SSD brauchen noch viel längere Zugriffe, einfach weil jeder Befehl auch einen Overhead hat und die SSD intern die Daten über die NANDs verteilen, da ein NAND Dies alleine eben sehr lahm ist und SSD daher die Geschwindigkeit nur über die Parallelität erzielen.
Länger als ein Fragment einer Datei wird ein Zugriff aber nie sein, denn dahinter stehen ja Daten einer anderen Datei und damit kann man dann nichts anfangen. Also werden auch die Zugriffe auf SSD langsamer, wenn die Dateien stark fragmentiert sind, was ja bedeutet das sie in viele kleinen Fragmenten an unterschiedlichen Adressen (LBAs) liegen und jedes Fragment extra adressiert werden muss. Das hat gar nichts damit zu tun wo die Daten dann jeweils im NAND stehen. Natürlich sind die Auswirkungen auf die Performance weitaus geringer als bei HDDs bei denen dann noch jeweils die langsamen Kopfbewegungen anfallen um die Position des nächsten Fragments zu erreichen, daher ist der Effekt bei SSDs meist allenfalls messbar.
burkm schrieb:
Es gibt Tools, mit denen man den Flash einer SSD testen kann... aber Defragmentierung ?
Was für Tools soll es geben mit denen man die NANDs einer SSD testen können soll? Sowas wäre mir nicht bekannt, man kann nur die S.M.A.R.T. Werte auslesen und die verwaltet der Controller. Ob da die Wahrheit steht oder nicht, ist alleine in der Hand des FW Programmierers. Die Fragmentrierung der Dateien und damit den Grad der Fragmentierung des Filesystems kann man auch bei SSD mit jedem Tool testen welches dies auch bei HDD anzeigen kann, außer SSDs wurden da explizit ausgesperrt, denn die Fragmentierung ist wie gesagt total unabhängig vom Medium.
robertsonson schrieb:
defrag ist bei ssds unnötig/schlecht für die zellen
Das ist zimlicher Unsinn,
denn bei extremer Fragmentierung kann die Performance sehr wohl leiden und schlecht ist es nur insofern, dass es wie bei jedem Schreibvorgang eben Verschleiß bewirkt. Defragmentieren ist ja nichts anderes als eine Reihe von Lese- und Schreibvorgängen, dass da gerade Defragmentiert wird, weiß die SSD (oder die HDD) gar nicht. Wenn also eine SSD bei der Defragmentiert stirb, war sie sowieso schon kurz vor dem Abnibbeln und wäre eh bald über den Jordan gegangen.
robertsonson schrieb:
und win7 macht es bei erkennung dann eben erst garnicht. so schlau ist win7 von selbst
Win 7 macht dies nicht automatisch im Rahmen Defragmentierdienstes, aber manuell kann man auch für SSD eine Defragmentierung mit den Bordmitteln anstoßen.
Xon2 schrieb:
Als Einstieg in die Materie defrag und ssds nochmal der Hanselman link:
Bitte nicht, Leute die Blödsinn schreiben sollte man ignorieren und nicht noch weiter verlinken. Gerade um das Thema hat der Typ sich doch nun wirklich nicht mit Ruhm bekleckert, aber darüber wird so viel Unsinn im Netz geschrieben....
Xon2 schrieb:
Offenbar wurde das ja ab win 8 auch wieder standardmässig im Rahmen des backup/Schattenkopie service implementiert.
Wie kommst Du auf backup/Schattenkopie service? Der Titel des Bildes in dem Beitrag von diesem Hanselman ist doch "Optimze Drives" und das ist der Storage Optimizer, keine Ahnung wie der im deutschen Windows heißt, aber sicher nichts mit Backup oder Schattenkopie. Dessen Vorgänger in Win 7 war der Defragmentierdienst.
Xon2 schrieb:
Hier geht es weniger direkt um reine Zugriffszeiten sondern anscheinend um die Integrität des file systems (und der anwachsenden file Systemtabelle).
Eben, NTFS hat offenbar Probleme in seinen Metadaten extrem fragmentierte Dateien, also solche Dateien die aus extrem vielen Fragmenten bestehen, zu verwalten. Dies kann auch eine Konvertierung von FAT32 zu NTFS unmöglich machen.
Xon2 schrieb:
Das war ja auch mein ursprünglicher Gedanke; dass durch den relativen hohen Fragmentierungsgrad (wobei 50% sicher weit vom Maximum entfernt sein sollte) ein Fehler in der file system Tabelle (wie auch immer genau das heißt) für den Absturz und Datenverlust gesorgt hat.
Der Fragmentierungsgrad des Filesystems ist einfach nur die Prozentangabe wie viele der Dateien denn Fragmentiert sind, also aus mehr als einem Fragment bestehen. Der sagt alleine sehr wenig aus, selbst bei HDDs ist es z.B. ein großes Problem wenn mitten in der Datei ein kleines Fragment einer anderen Datei steht, denn dann erfordert es praktisch ja auch keine Kopfbewegung um das nächste Fragment anzufahren, welches ja gleich darauf folgt. Auch macht es eine großen Unterschied ob nun alle fragmentierten Dateien gerade mal aus zwei oder drei Fragmenten bestehen, oder ob es Hunderte sind. Richtig wäre es eigentlich die Gesamtzahl der Fragmente durch die Anzahl der Dateien zu teilen, daran würde man dann viel besser erkennen wie stark ein Filesystem wirklich fragmentiert ist.
yxcv schrieb:
Deine SSD wird schlicht das Lebensende erreicht haben.
Glückwunsch dass die nur 120GB kleine SSD überhaupt 33.241 GB geschrieben und 13.500 Betriebsstunden geschafft hat.
Immerhin wurde so jede Speicherzelle gut 270 Mal überschrieben.
Wie kommst Du auf den Blödsinn? Erstens wären 270 P/E Zyklen nichts, dann haben
laut dem Screenshot in Post #7 die NANDs seiner 830er 0x289 = 649, aber die sind mit 3000P/E Zyklen spezifiziert und dürften einige mehr aushalten bevor sie wirklich hinüber sind. Es gibt auch keine Fehler die auf NAND Probleme hindeuten.
Von deren Nachfolger der 840 Pro 128GB gibt es
hier einen Endurance Test, die schneidet dort aber bzgl. der Schreibgeschwindigkeit viel besser als bei Techreport ab. Die 128GB 840 Pro hat dort mehr als 3PB geschrieben, die 256GB müsste also etwa doppelt so viel schaffen, wird bei der "Geschwindigkeit" mit der Techreport arbeitet also noch einige Jahre brauchen und längst nicht mehr aktuell sein, wenn der Test zuende geht.
Übrigens sieht man dort auch gut, wie konservativ die spezifizierten Zyklen angegeben sind:
Weiter sieht man gut, dass die Badblock wie bei vielen anderen SSD im
Dauerschreibtest auf xtremesystems.org so etwa nach der Hälfte der Zeit anfangen zu steigen:
Aber erst wenn die ECC-Recoveries massiv ansteigen, dann wird es wirklich kritisch und die NANDs sind dem Ende nah. Die 840 Pro hält rund 6 mal so viel aus und der Verschleiß fing erst wirklich nach der dreifachen Anzahl von P/E Zyklen an und kritisch wird er, wenn die ECC Fehlerrate anfängt massiv zu steigen.
Wobei diese ECC Fehler der 840 Pro noch alle korrigiert wurden:
Dort gibt es einen Fehler, den demnach könnte 183 zwei Bedeutungen, entweder die Summe von 181 und 182 oder eben die ECC Fehler die nicht mehr korrigiert werden konnten. Aber die Kurve passt gut zu der der von Program Fail Count, demnach wäre also die Bedeutung als Runtime Bad Count für das Attribut 183 anzunehmen, so zeigt Magician das z.B. auch an und dort steht das 187 Uncorrectable Error Count, es dort also eine Tippfehler gibt und das zweite 183 eigentlich 187 sein müsste. Leider wurden aber dort keine Ausgabe zu dem Wert Uncorrectable Error Count gemacht, das wären die bösen die dann für die UBER verantwort sich. Vermutlich war da einfach nichts spanndes passiert, aber den Werte müsste man halt im Auge behalten, wenn man zur UBER etwas aussagen will, denn das sind dann wirklich die Fehler die bei HDDs den schwebenden Sektoren entsprechen.
yxcv schrieb:
Bei so alten Modellen war solch eine Leistung noch keine Selbstverständlichkeit.
Selten musst ich so einen Schwachsinn lesen, gerade diese alten Samsung 830 oder auch Crucial m4 halt extrem viele Schreibvorgänge aus. Damals waren die Controller schon weitaus besser als die ganz alten Controller der ersten SSD und in Enterprise SSDs wurden noch keine MLC NANDs verbaut, daher landeten auch die besten Qualitäten noch in solche Consumer SSDs, während sie dann bald darauf als eMLC in Enterprise SSDs verwendet wurden.
yxcv schrieb:
Es wird hier wohl nicht der Fall sein (da die SSD ab Ende ist), aber die Meldung "ntoskrnl.exe ist beschädigt" gab es früher auch aufgrund von fehlerhaften Chipsatztreibern.
Die SSD ist nicht am Ende, die ist gerade eingefahtren und wie wir nun wissen, war nur eine Datei beschädigt, was aber nicht an der SSD gelegen haben dürfte, sondern am Rechner. Da reicht schon ein RAM Fehler und schon wird mal eben versehentlich auf eine andere Adresse geschrieben als eigentlich vorgesehen oder eben ein Bug irgendwo im System der dazu führt.
Wenn noch über 80% der P/E Zyklen der NANDs übrig sind und die SSD gerade mal 13574 Betriebsstunden runter hat, dann ist eine ordentliche SSD wie die Samsung 830 gerade mal eingefahren, wie ein Auto nach 10.000km und noch weit davon entfernt am Ende zu sein. Keine Ahnung woher Du meinst Ahnung von SSDs zu haben, aber wenn diese auf eigenen Erfahrungen beruhen soll, dann solltest Du aufhören igrendwelche Schrott SSD zu kaufen und nur noch
SSDs von NAND Herstellern oder deren Tochterfirmen kaufen und zwar solche mit einem DRAM Cache, die
DRAM less SSD sind im Alltag enttäuschend lahm.
