Updater gibt es nur für Windows und ist ein 220 MB Dashboard
Die Firmware liegt irgendwo auf wddashboarddownloads.wdc.com
Bei anderen Devices von WD sind die Dateien obfuscated.
You do not have permission to view link please Anmelden or Registrieren
crazy
Die Platte hat wohl außerdem silent-data-corruption Probleme mit 4K / NCQ_TRIM
You do not have permission to view link please Anmelden or Registrieren
You do not have permission to view link please Anmelden or Registrieren
und steht nicht auf der Blacklist
You do not have permission to view link please Anmelden or Registrieren
Also Vorsicht!
Nachtrag:
"Western Digital schliesst Milliarden-Übernahme von SanDisk vorzeitig ab"(zdnet.de)
"Flipping the PCB over, we see the SanDisk logo so we dug up all images of SanDisk SSDs and noticed that this design" (You do not have permission to view link please Anmelden or Registrieren)
"SanDisk has released the ISO firmware images to allow SSD firmware update on operating systems that are NOT supported" (kb.sandisk.com) those are linux images
Schraub sie mal auf
Die Bezeichnung "Quirks-Liste" wäre wohl angemessener.
Wenn du den Weg gehst, mach Kopien, insbesondere von den Release-Notes, Die 220MB Bloatware wird die Platte identifizieren und den Server nach der neusten Version fragen und der schickt ein Archiv mit den Daten. Die Software bietet dir an das Update durchzuführen, oder ein iso zu erstellen, oder einen USB Stick. Die iso kopierst du dir auch, da ist wahrscheinlich SanDisk WDC non-free Linux drauf. Das schafft eine Umgebung in der niemand die Platte stresst, zeigt ein paar Daten, will ein ok und schickt dann ein ata download microcode, ein paar propietäre subcommands und eine bin mit ner höheren Versionsnummer und geht wieder aus
Gibt auch ein Intel Linux, Samsung hingegen nutzt DOS,Alternative im Marktsegment defekter Geräte von zwielichtigen Herstellern?
Das ist so lala.
Wahrscheinlich wird dir da der RAW-Wert von SMART angezeigt. Das kann man in den Smartmontools umstellen, damit da die °C ausgedroppt werden, aber im Prinzip kannst du den Wert auch einfach ignorieren, bei SSDs dürfte der wesentlich unproblematischer sein als bei HDDs.
- Artikel:
Quelle:
DRAM hat das Gerät keine, braucht also keinen NAND um den Cache bei Stromausfall zu retten.
smartctl (8) Control and Monitor Utility for SMART Disks
-x, --xall
Prints all SMART and non-SMART information about the device.
# smartctl -x <DEVICE> >> kingstonA400.smartctl.loghdparm (8) get/set SATA/IDE device parameters
-I Request identification info directly from the drive, which is
displayed in a new expanded format with considerably more detail
than with the older -i option.
# hdparm -I <DEVICE> >> kingstonA400.hdparm.logStartet bei 100
Das ist eine Glaubensfrage.
SSD
- /efi (100M vfat)
- /boot (1G)
- LUKS2
- cryptswap
- /
HDD
- LUKS2
- /dataNaja, ich weiß schon, wie TRIM und GC auf ner SSD laufen, daher frage ich mich ja, woher das Märchen kommt, dass die SSD eine 10GB-Partition dafür braucht. Die logisch angezeigten GB kann man alle verbraten, das grätscht TRIM nicht in die Parade, das hat dafür extra (unsichtbaren) Speicher...
Aus der praktischen Erfahrung heraus ist BTRFS auf SSDs NICHT zu empfehlen. Zumindest bei uns in der Arbeit zerlegt die Optimierungsstrategie von BTRFS völlig die inkrementellen Backups auf dem Cluster, und wenn Suse drauf genutzt wird, kotzt einem der Snapper-Dienst ständig Scheiße auf die Platte. EXT4 oder XFS, den Rest kann man den Hasen geben, zumindest wenn ein RAID verwendet werden soll, weil BTRFS dann nicht mehr direkt mit TRIM reden darf.
Da sollte man idealerweise gar keine Parameter selbst angeben, sofern man nicht GANZ GENAU weiß, was man da treibt. Die Standardoptionen sind üblicherweise auf hohe Datensicherheit ausgelegt, jede Abweichung davon erfordert sehr genaue Kenntnis darüber, wie die Verschlüsselung funktioniert und implementiert ist. Die beste Verschlüsselung ist fürn Arsch, wenn sie (aufgrund falscher Parameter) schlecht implementiert oder falsch eingerichtet ist.
Anandtech hat 2012 in den Consumer SSD Reviews dazu geraten. Deswegen hab ich es ja verlinkt.
Da die Quelle das nicht aussagt ist die Attribution natürlich unverschämt und wird gestrichenCoW und Snapshots sind schon was schönes, aber, wenn man das nicht benutzt, oder anders rainlayered (LVM2), oder oldstable verwendet...
eine?
Das schnelle Löschen von LUKS funktioniert nicht mit SSDs gegen forensische Angriffe.
ikachu:Gib mal mehr Details. Was für ein RAID und warum darf es das nicht?
Full Ack
Standards ändern sich.
$ cat /proc/crypto | sed -n '/xts/,/^$/p' | less
Wenn du diese Stelle hier meinst:
solltest du vielleicht dein Englisch nochmal auffrischen. Hier wird keine leere Partition erstellt, hier wird ein Teil gar nicht partitioniert, d. h. dem Drive und dessen Controller explizit gesagt, dass es nicht verwendet wird.Anandtech schrieb:
Klar. Ein Cluster arbeitet im Idealfall immer auf RAIDs, allein schon wegen Performance und Ausfallsicherheit.
Jedes RAID, das als Layer unter BTRFS liegt, wird einen Zugriff auf TRIM durch das Filesystem verhindern, weil RAID üblicherweise hart auf Sektoren arbeitet, d. h. wenn überhaupt es dem Festplattencontroller überlässt, welche Daten er wo hin schreibt, sofern eine Ansprache auf Sektor 23423346496 immer noch die gleichen Daten zurückliefert, die der Controller darauf abgespeichert weiß. Es wäre mir neu, dass z. B. mdadm oder Hardware-RAID-Controller den darüber liegenden Layern die Möglichkeit geben, direkt mit der Festplatte zu reden. Wenn du natürlich BTRFS nutzt, um RAID zu machen, ist das was anderes.
Ja, richtig, Kryptographie ist ein bewegliches Ziel. Daher werden auch neuere Versionen mit neueren Empfehlungen ausgegeben, und man nutzt nicht Software von vor 20 Jahren. Die Devs oder Maintainer überlegen sich gerade bei neuen Major-Versionen sehr genau, welche Standardeinstellungen sie nutzen, und die sind sicher weiter in der Materie drin als so ziemlich jeder hier. Ich weiß nicht, was du diesbezüglich an meiner Aussage zu meckern hast.
Aber selbstverständlich doch. Einige Desktop-Distros dürften so eine Warnung auch enthalten.
Sorry. Ich schweife gerne ab. Redest du über Hardware-RAIDs? Die Chips auf einer SSD mappen auch. Das ist doch die Sache mit der Garbage Collection. Der TRIM soll an die Firmware von der Platte, nennt sich auch discard und verwirft nicht mehr genutzte Sektoren. Der kommt von weiter oben, irgendwo von einem Layer, der weiß, ob die Daten nun ungenutzt sind, oder nicht. Was hat RAID damit zu tun?
Die "JA und Weiter" Philosophie. Was ist das default Partitionsschema bei Debian in der SSD Laptop Edition? Ich weiß es nicht. Ist es egal, weil es gut ist?
Ich denke tatsächlich, dass das Anfangsprobleme waren, die wir mittlerweile im Griff haben. Die eigentliche Performance-Drossel ist vermutlich eher eine zu gering dimensionierte Anbindung auf dem Mainboard als die SSD selbst. Zumindest legt das meine Erfahrung so nahe - Gaming-PC mit aktueller SSD, aber fast allen SATA-Anschlüssen voll, ist schnachlangsam, während das gebrauchte Notebook mit ner SSD von 2013 wie eine Rakete abzischt, genauso wie der Server und das Arbeitsnotebook mit aktueller SSD. Nimmt sich alles nicht viel, zumindest nicht vom Gefühl her. An Benchmarks sieht man es sicher irgendwo, aber mal ehrlich: Benchmarks sind auch nur die halbe Wahrheit, und auf Supercomputing-Ebene sagt man diesbezüglich sogar, dass man für den Wunschplatz im internationalen Ranking nur mal verschiedene Benchmarks testen muss, und den mit der größten Ausbeute dann noch optimieren. Mit Realität bzw. Praxis hat das alles wenig zu tun.
Hui, da war mein Stand ganz schön alt. Stimmt tatsächlich, TRIM geht schon seit Langem durch mdadm durch, und das dürfte auch für Hardware-Controller gelten. ABER: So einfach ist es offenbar nicht. Das Problem ist das Handling der Befehle durch die SSD selbst - nicht jede löscht dann tatsächlich die betroffenen Bereiche, was anscheinend in einem RAID5 zu ziemlichen Problemen führen kann:
DAS kann ich nachvollziehen. Problem ist: Wenn ich mir ein neues System einrichte, gucke ich mir die aktuellen Defaults an, les mich ein, entscheide dann eigentlich immer, dass die Defaults eine sinnvolle Abwägung waren (hab das glaub erst einmal nicht gemacht, weil die Nachfolgeversion die Defaults umgebogen hat und ich die Umentscheidung nachvollziehen konnte). Allerdings hab ich glaub ich nen bisschen mehr Hintergrund als der 0815-Neuling. Insofern rate ich tatsächlich Anfängern bei Debian zu einem Ja&weiter, bis auf eine einzige Default-Einstellung - "Soll root das Anmelden erlaubt werden?" <--- NEIN!
Wenn die Firmware auf einer kompletten Serie an Platten spinnt, bringt dir das RAID genau null. Da wird üblicherweise zwar drauf geschaut, dass die Chargen unterschiedlich sind, aber Firmwareversionen werden tunlichst gleich gehalten, und Modellreihen großteils auch. Wir durften mal ne Palette zurückschicken, weil der Supplier gedacht hat, es wäre kein Problem, wenn das alles die gleiche Charge ist... waren ja nur ein paar hundert Kilo Platten...
Öhm ja
