Crucial Firmware Update lässt sich nicht von USB booten?

[Falc410]

Ja, aber das flashen unter Windows hat ja nur 5 Sekunden gedauert und nicht geklappt, trotzdem behauptet die Festplatte mit 070H zu laufen. Im Internet bin ich auf einen Thread gestossen in dem jemand genau das gleiche Problem hatte. Er hat dann auf die alte FW zurück geflasht und dann wieder auf de 070H. Davon abgesehen dass ich die 040H nicht zum download finde, ist mir das natürlich alles etwas riskant. Sicherheitshalber hab ich schon eine MX100 als Ersatz besorgt.

 

[Hallo32]

Das Flashen selbst geht sehr schnell. (So ein Firmware Update hat eine Größe von einigen KB bis 1-2MB.)
Wenn kein Flash stattgefunden hätte, dann würde CrystalDiskInfo dir noch die alte Version anzeigen. Woher soll die Software sonst wissen, welche Version du gerade versucht hast zu flashen?

 

[Holt]

Wenn die M4 sich intern notiert hat, dass diese nicht wie erwartet "ausgeschaltet" wurde, dann macht diese beim nächsten Start ein Selbsttest.

Es ist wohl konkreter so, dass sie beim Ausschalten die Mappingtabelle nicht im NAND aktualliert hatte und diese dan durch die m4 Power Cycle Wiederbelebung aufgrund der Daten in den NANDs rekonstruiert, denn Micron/Crucial speichert auch die LBAs bei den Daten selbst ab, die NAND Page und Blöcke habe ja immer einige Bytes Extra für ECC und Verwaltungsdaten und die nutzt Micron eben dazu die LBAs mit zu den Daten zu schrieben, nennt sich DataSAFE:

DataSAFE ensures that all data, read or written, is intact. When writing data, Micron not only writes the data from the host to the NAND but also the metadata associated with the data (i.e. its logical block address/LBA). When the host then requests the data to be read from the drive, the LBA of the data is first compared against the value in the L2P table (logical to physical -- Micron's name for the NAND mapping table) before sending the data to the host. This ensures that the data that is being read from the NAND is in fact the same data that the host requested. If the LBA values of the NAND and L2P table are different, then the drive will have to rely on ECC or RAIN to recover the correct data.

Das hat eben vor allem auch den Vorteil, dass sich die SSD in so einem Fall ohne Datenverlust die Mappingtabelle rekonstruieren kann, eine Intel 320er die von den 8MB Bug betroffen ist, was letztlich die Ursachen haben dürfte, muss man über ein Secure Erease löschen und verliert die Daten, bei Micron / Crucial geht es ohne Datenverlust. Schlau gemacht und funktioniert auch bei m500, m550, MX100 und sicher auch bei der MX200, obwohl es dort wegen der Stützkondensatoren eigentlich nicht nötig sein sollte. Aber in einem Forum gab es dann Fall schon einmal, immer können die Kondensatoren eine Korruption der Mappingtabelle offenbar auch nicht verhindern, es ist ja nur eine Client-Class Lösung mit relativ wenig Kondensatorkapazität.

 

[Hallo32]

@Holt

Alles richtig, ich wollte das Thema jetzt nur nicht noch erweitern.