[Sammelthread] Kaufberatung und Fragen zu SSD

Status
Für weitere Antworten geschlossen.
Das kann man schwer sagen, technisch wäre es kein Problem. Da von dem 16nm NANDs auch noch eine Version mit 256Gigabit Diesze kommen soll, wäre sogar eine 2TB Version denkbar. Ich würde mir eine wünschen und wohl auch kaufen, wenn der Preis pro GB in dem Rahmen der anderen Versionen liegt.
 
Dass Firefox die CPU nicht fordern würde, ist meines Erachtens ein Trugschluss. Wenn ich unter Linux einen Firefox zum Surfen und zwei weitere Firefoxe mit je einem Facebook-Profil offen habe, ist meine Notebook-CPU (nur ein alter Core2 Duo mit 1,8GHz) bei 100% Auslastung. Wenn ich dann im Surf-Firefox noch ein paar Tabs offen habe, die Flash nutzen, wird es schon arg zäh.

Wie ich schon schrieb und Holt auch nochmal bestätigt hat: Ohne eine vernünftige Problemanalyse ist keine vernünftige Lösung möglich. Dann kannst du auf Verdacht einen Haufen Geld investieren und die allerschnellste SSD einbauen, um entweder am Ende keine Besserung zu haben, weil das Problem an anderer Stelle liegt, oder eine Verbesserung zu haben, die auch mit einer billigeren SSD zu haben gewesen wäre. Von Kaffeesatzleserei kann dir keiner eine Empfehlung geben. Fest steht, dass kein Videostream in Echtzeit - auch in mehrfacher Ausführung - eine SSD auch nur ansatzweise ins Schwitzen bringt - eine HDD aber wegen der vielen parallelen Zugriffe durchaus zum Kollaps.
 
Dass Firefox die CPU nicht fordern würde, ist meines Erachtens ein Trugschluss

Bei mir braucht das gesamte System mit gestartetem Firefox und ssh-Sitzung 0,7%.

Ohne eine vernünftige Problemanalyse ist keine vernünftige Lösung möglich.

Ich versuche demnächst bei einem rsync eine iotop bzw. top-Ausgabe zu machen.

Nun habe ich aber was anderes entdeckt, dass die Entscheidung wieder in Richtung SanDisk lenkt:

http://wiki.ubuntuusers.de/SSD/TRIM

Automatischer TRIM ab Ubuntu 14.04 LTS

Mit Ubuntuversion 14.04 wurde ein wöchentlicher automatischer TRIM bei einigen SSD eingeführt. Dazu wird die Datei fstrim im Verzeichnis /etc/cron.weekly erstellt, die wiederum das Script fstrim-all ausführt. Dieses durchläuft alle aktiven Dateisysteme auf der Suche nach einer SSD. Stellt es fest, dass sich ein oder mehrere Dateisysteme auf einer SSD befinden, wird fstrim automatisch gestartet.

Zurzeit wird der TRIM noch über eine Positivliste (englisch: Whitelist) durchgeführt, da es bei einigen SSD mancher Hersteller offenbar zu Datenverlusten kommen kann, wenn parallel zum TRIM viele I/O-Operationen stattfinden (siehe 1259829). Ein automatischer TRIM wird derzeit bei SSDs von Intel, Samsung, OCZ, SanDisk und Patriot durchgeführt.

Möchte man eine vorhandene SSD von einem Hersteller auto-trimmen, der nicht auf der Whitelist steht (weil man sich sicher ist, dass die eigene SSD nicht von diesen Problemen betroffen ist), kann man in der Datei /etc/cron.weekly/fstrim die Option --no-model-check an den fstrim-Befehl hängen, so dass der Befehl dann wie folgt aussieht:

Aber:

http://forums.crucial.com/t5/tkb/articleprintpage/tkb-id/ssd@tkb/article-id/48

Crucial SSDs and TRIM/Garbage Collection

Since not all operating systems support TRIM, Crucial SSDs have a special feature called Active Garbage Collection. Active Garbage Collection is a process that helps an SSD maintain optimal performance by freeing up memory sectors that are no longer in use. Garbage collection is part of the SSD itself and thus not dependent on your computer’s operating system. Since garbage collection is part of the SSD’s firmware, it works regardless of which operating and filing systems your computer is using.

Note: Garbage collection only works when your Crucial SSD is idle, so make sure to configure your system so it doesn’t go to sleep when it’s idling. Garbage Collection takes time to do its job, but as long as it gets time to idle every now and then, your Crucial SSD will maintain its high level of performance over time.

Vielleicht hilft diese von einem anderen(!) PC für die Analyse, da wird es auch sehr langsam, sobald rsync läuft:

Code:
top - 04:31:04 up 58 min,  2 users,  load average: 1.92, 2.36, 2.32
Tasks: 203 total,   4 running, 198 sleeping,   0 stopped,   1 zombie
Cpu0  : 18.2%us, 16.8%sy,  0.0%ni, 39.7%id, 12.1%wa, 13.1%hi,  0.0%si,  0.0%st
Cpu1  : 20.8%us, 14.4%sy,  0.0%ni, 14.1%id, 50.7%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8170180k total,  8039636k used,   130544k free,     3252k buffers
Swap:  8007676k total,        0k used,  8007676k free,  7491064k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                               
23002 root      20   0 26872 6620  964 R   33  0.1   1:48.91 rsync                                                                                                                                                 
23004 root      20   0 27328 1176  348 R   33  0.0   1:45.83 rsync                                                                                                                                                 
   46 root      20   0     0    0    0 S    2  0.0   0:28.62 kswapd0

Code:
iotop -bo --iter=5 | cut -c1-100
Total DISK READ:       0.00 B/s | Total DISK WRITE:       0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
23002 be/4 root       31.19 M/s    0.00 B/s  0.00 %  0.00 % rsync -e ssh -rlptgoDv --stats --delete 
23004 be/4 root        0.00 B/s   23.90 M/s  0.00 %  0.00 % rsync -e ssh -rlptgoDv --stats --delete 
Total DISK READ:      82.42 K/s | Total DISK WRITE:      87.32 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
23002 be/4 root       40.96 M/s    7.85 K/s  0.00 % 35.23 % rsync -e ssh -rlptgoDv --stats --delete 
23003 be/4 root       82.42 K/s    0.00 B/s  0.00 %  0.00 % rsync -e ssh -rlptgoDv --stats --delete 
23004 be/4 root        0.00 B/s   42.82 M/s  0.00 %  0.00 % rsync -e ssh -rlptgoDv --stats --delete 
Total DISK READ:       0.00 B/s | Total DISK WRITE:      74.04 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
23002 be/4 root       52.15 M/s    3.91 K/s  0.00 % 49.20 % rsync -e ssh -rlptgoDv --stats --delete 
  280 be/4 root        0.00 B/s    0.00 B/s  0.00 % 20.20 % [kworker/u16:7]
21670 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.55 % hald-addon-storage: polling /dev/sr0 (ev
23004 be/4 root        0.00 B/s   52.12 M/s  0.00 %  0.00 % rsync -e ssh -rlptgoDv --stats --delete 
Total DISK READ:      23.47 K/s | Total DISK WRITE:      89.98 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
23002 be/4 root       35.28 M/s    3.91 K/s  0.00 % 35.66 % rsync -e ssh -rlptgoDv --stats --delete 
23003 be/4 root       23.47 K/s    0.00 B/s  0.00 %  0.00 % rsync -e ssh -rlptgoDv --stats --delete 
23004 be/4 root        0.00 B/s   35.44 M/s  0.00 %  0.00 % rsync -e ssh -rlptgoDv --stats --delete 
Total DISK READ:       0.00 B/s | Total DISK WRITE:      74.00 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
23002 be/4 root       53.76 M/s    0.00 B/s  0.00 % 53.54 % rsync -e ssh -rlptgoDv --stats --delete 
  280 be/4 root        0.00 B/s    0.00 B/s  0.00 % 18.45 % [kworker/u16:7]
21670 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.56 % hald-addon-storage: polling /dev/sr0 (ev
  288 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.31 % [kworker/u16:8]
23004 be/4 root        0.00 B/s   51.46 M/s  0.00 %  0.00 % rsync -e ssh -rlptgoDv --stats --delete
 
Zuletzt bearbeitet:
Die Crucial SSDs haben keine Probleme mit TRIM oder Datenverlust durch TRIM, das ist Quatsch mit Soße, keine Ahnung wieso Crucial da nicht in der Positivliste steht. Außerdem müsste man so eine Liste korrekt bis zu den jeweiligen Modellen und FW Version auflösen, wenn man Modelle mit Problemen ausschliessen wollte und nicht nur bis zu den Herstellern. Das war in der SSD Steinzeit vielleicht mal ausreichend, als jeder nut ein Modell hatte. Die erste Crcuial SSD war die M225 und die hatte einen Indilinx Barefoot, der TRIM erst mit einer recht späten FW erhalten hat, vielleicht fehlt Crucial ja deshalb.

Man sollte unter Linux auf jeden Fall die Einträge der fstab prüfen und dort ggf. den nötigen Eintrag für online TRIM eintragen, da es nicht immer automatisch richtig gemacht wird.

Code:
Cpu0 : 18.2%us, 16.8%sy, 0.0%ni, 39.7%id, 12.1%wa, 13.1%hi, 0.0%si, 0.0%st
Cpu1 : 20.8%us, 14.4%sy, 0.0%ni, 14.1%id, 50.7%wa, 0.0%hi, 0.0%si, 0.0%st
Da sehe ich nur 2 CPUs / Kerne (drücke nach dem Start von top 1, dann werden alle Kerne aufgeklappt), und mit 12,1% bzw. 50,7% viel Wait for I/O, die warten also reichlich auf die Laufwerke, dass sollte dramatisch abnehmen, wenn die Daten auf die gewartet wird auf einer SSD liegen.
 
Um das rsync-Szenario noch mal zu verstehen.
Du synchronisierst innerhalb einer Festplatte von einer Partition auf die andere?
Wieviel Daten und Dateien sind das so?

Beim geposteten top wird rsync über ssh verwendet wie es aussieht. Ist das so?
Wäre ja für ein lokalen Setup nicht notwendig.

++
Umkopieraktionen sind natürlich langsam auf einer Festplatte. Wenn Du von der gleichen Platte dann noch Dein System holst und ein Programm starten willst, dauert das.
Das Szenario ist bei einer SSD viel besser.
Es wäre auch viel besser, wenn Du mit 2 Festplatten arbeitest, wo die eine auf die andere gesyncht wird.

Wenn man solch Dinge wie Videoschnitt usw. sollte man für gute Performance immer von einer Quell- auf eine Zielplatte arbeiten. Eine Dritte für System und tempfiles wäre dann auch gut.

++
Selbst eine hohe Belastung einer Festplatte ist aber trotzdem kein Grund, dass z.B. der Mauszeiger hängen bleibt.
Ich würde an Deiner Stelle nochmal genau checken, dass der Sata-Controller im BIOS auf AHCI steht und unter Linux der optimale Treiber verwendet wird (was auch immer der ist).

++
Alle aktuellen SSDs haben Trim und Garbage Collection.
Garbage Collection defragmentiert quasi den freien Speicherbereich in der SSD und löscht den (hoffentlich) auch schon, so dass der bei einem Schreibvorgang sofort und möglichst schnell beschrieben werden kann.
Mit Trim wird der SSD gesagt, dass (weitere) Speicherblöcke frei sind. Der freie Bereich ist einfach größer, der bei Garbage Collection berücksichtigt werden kann. Dementsprechend kann auch mehr schnell geschrieben werden.
 
Holt schrieb:
Die Crucial SSDs haben keine Probleme mit TRIM oder Datenverlust durch TRIM, das ist Quatsch mit Soße, keine Ahnung wieso Crucial da nicht in der Positivliste steht. Außerdem müsste man so eine Liste korrekt bis zu den jeweiligen Modellen und FW Version auflösen, wenn man Modelle mit Problemen ausschliessen wollte und nicht nur bis zu den Herstellern. Das war in der SSD Steinzeit vielleicht mal ausreichend, als jeder nut ein Modell hatte. Die erste Crcuial SSD war die M225 und die hatte einen Indilinx Barefoot, der TRIM erst mit einer recht späten FW erhalten hat, vielleicht fehlt Crucial ja deshalb.
In dem im Artikel verlinkten Bug-Report geht es um eine M500.

Weiter unten ist dann aber auch folgendes zu lesen:
Ganz durch ist damit das Thema aber immer noch nicht. Im Kommentarthread des Bug-Reports geht es weiter und auch im Crucial Forum gibt es dazu einen Thread:
 
Zuletzt bearbeitet:
Da sehe ich nur 2 CPUs

Ich hatte ja auch geschrieben: "Vielleicht hilft diese von einem anderen(!) PC für die Analyse" In diesem Fall war es nur ein Dualcore.
Beim geposteten top wird rsync über ssh verwendet wie es aussieht. Ist das so?
Wäre ja für ein lokalen Setup nicht notwendig.

Das ist ein Beispiel wo via ssh vom 8-Core auf den Dualcore gesynct wird. Meine Erfahrung ist, wenn top viel load anzeigt, dann bremsen die Festplatten.

Es wäre auch viel besser, wenn Du mit 2 Festplatten arbeitest, wo die eine auf die andere gesyncht wird.

Das ist die Regel oder eben ein anderer PC, genauso wird auf eine andere HD gesynct, wenn gerendert wird, ich habe ja 4 HDs verbaut, 1 für System, 1 für die Videoquelle, 1 für Audioquelle, 1 für die gerenderte Datei.

Ich würde an Deiner Stelle nochmal genau checken, dass der Sata-Controller im BIOS auf AHCI

Mache ich ASAP, schreibe gerade damit. Sollte das nicht default sein? Der Mauszeiger hängt nur selten, kann aber vorkommen.

Alle aktuellen SSDs haben Trim und Garbage Collection.
Garbage Collection defragmentiert quasi den freien Speicherbereich in der SSD und löscht den (hoffentlich) auch schon, so dass der bei einem Schreibvorgang sofort und möglichst schnell beschrieben werden kann.
Mit Trim wird der SSD gesagt, dass (weitere) Speicherblöcke frei sind. Der freie Bereich ist einfach größer, der bei Garbage Collection berücksichtigt werden kann. Dementsprechend kann auch mehr schnell geschrieben werden.

Da muss ich noch recherchieren welches Journaling-Filesystem ich verwenden will. Eventuell XFS oder BTRFS. BTRFS ist aber mit normalen SATA-HDs mit rsync deutlich langsamer. Ext4 mag ich nicht so.

In dem im Artikel verlinkten Bug-Report geht es um eine M500.

Datenverlust und PC-Ausfall ist mir der billigeen Preis nicht wert. Ich überlege nun eine SSD aus der Whitelist.

Somit bieten sich auf die Schnelle folgende 2 Modelle an, aber vielleicht kennt ja wer etwas anderes:

http://geizhals.eu/?cat=hdssd&xf=32...834_3~4832_1~2236_75~222_500~3313_2013&sort=p

SanDisk Extreme II für Desktops 240GB, SATA 6Gb/s (SDSSDXP-240G-G26) ab €115,85
http://geizhals.eu/sandisk-extreme-ii-fuer-desktops-240gb-sdssdxp-240g-g26-a961158.html

OCZ Vertex 460 240GB, SATA 6Gb/s (VTX460-25SAT3-240G) ab €123,90
http://geizhals.eu/ocz-vertex-460-240gb-vtx460-25sat3-240g-a1059572.html

Gibt es einen Grund, eine der beiden vorzuziehen? eine SSD mit 256GB wäre mir lieber.
 
Dann weißt Du jetzt hoffentlich, wie Du Wait-I/O identitfizieren kannst und damit auch, welches Potential die SSD auf dem 8-Kerner beim Rendern bringen kann.

Von den beien würde ich die SanDisk bevorzugen, die ist günstiger und ob OCZ nun unter dem Dach von Toshiba seine Qualitätsprobleme alle im Griff hat, würde ich persönlich erst noch abwarten wollen. Auf jeden Fall ist die Schreibrate bei den OCZ SSD mit Vorsicht zu sehen, da OCZ die ganze Kapazität immer als Pseudo-SLC verwendet, also immer nur das erste Bit schreibt, was schnell geht aber womit die Schreibrate massiv einbricht, wenn mehr als die Hälfter (des vorher freien?) NANDs beschrieben wurde.
 
Zuletzt bearbeitet:
Dann weißt Du jetzt hoffentlich, wie Du Wait-I/O identitfizieren kannst und damit auch, welches Potential die SSD auf dem 8-Kerner beim Rendern bringen kann.

Ich kann die Tools leider nicht sicher interpretieren, aber ich probiere jetzt einfach die Sandisk aus.

Zum Thema AHCI, weiter oben. AHCI war im BIOS / UEFI deaktiviert. Ich habe es nun aktiviert. Wozu ist AMD AHCI Bios ROM? Das ist deaktiviert.

Außerdem fällt mir auf, dass Linux beim Booten AHCI zu aktivieren scheint, auch wenn es deaktiviert ist, wie ich mit dmesg sehe:

Code:
[    0.366415] pci 0000:00:11.0: set SATA to AHCI mode
[    1.527844] ahci 0000:00:11.0: version 3.0
[    1.528034] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
[    1.528037] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part 
[    1.528684] scsi4 : ahci
[    1.528777] scsi5 : ahci
[    1.529174] scsi6 : ahci
[    1.529344] scsi7 : ahci
[    1.529575] ahci 0000:06:00.0: irq 88 for MSI/MSI-X
[    1.529686] ahci 0000:06:00.0: AHCI 0001.0100 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
[    1.529691] ahci 0000:06:00.0: flags: 64bit ncq pm led clo pmp pio slum part 
[    1.530173] scsi8 : ahci
[    1.530275] scsi9 : ahci
 
Wenn ich höchsten Wert auf die dauerhafte Schreibrate legen würde, wäre für mich auch die SanDisk Extreme II erste Wahl, da sie sehr schnell und immer noch vergleichsweise preisgünstig ist. Für Videobearbeitung im Idealfall in doppelter Ausführung, wie oben schon von klampf geschrieben.

Ich würde wahrscheinlich nach und nach 1:1 die HDDs durch SSDs ersetzen. Angefangen bei der Systemplatte, die dann ja weder allzu groß noch allzu gut schreibend sein muss, und dann die beiden Video-Platten. Abhängig von Datenmenge und -rate kann Audio ja vielleicht auch von der System-SSD mit bedient werden. Die überflüssigen HDDs kannst du ja verkaufen, um die finanzielle Situation etwas zu entspannen.

EDIT: Wenn AHCI im BIOS und damit hardwareseitig deaktiviert ist, kann das Betriebssystem da softwareseitig nichts dran ändern. Es mag sein, dass Linux trotzdem die AHCI-Befehle verwendet, der Controller auf dem Mainboard und danach die SSD aber nichts damit anfangen können. Heutzutage ist AHCI per Default aktiviert (meines Wissens Voraussetzung für die Windows-8-Zertifizierung), wenn das Board aber schon ein paar Jahre alt ist, dann ist es noch auf XP-Kompatibilität getrimmt, das von Haus aus nicht mit AHCI umgehen kann.
 
Zuletzt bearbeitet:
Was das AMD AHCI ROM genau macht, kann ich Dir auch nicht sagen, das scheint aber auf die Performance keinen Einfluss zu haben. Den Modus, IDE, AHCI oder RAID, kann aber wender Linux noch ein anderes OS einstellen, das geht nur im BIOS, da dort der SATA Controller initialisiert wird. Zumindest war es vor UEFI so und ich wüsste nicht, dass sich das mit der Einführung von UEFI geändert hätte und wenn, dann wäre es ja überflüssig dieses dort einzustellen.
 
Ich weiß nur, dass Linux einige Bios-Einstellungen ignorieren kann, ob das bei AHCI auch so ist, keine Ahnung. Es ist ja kein Problem das umzustellen, aber Unterschied merke ich keinen.
Ich würde wahrscheinlich nach und nach 1:1 die HDDs durch SSDs ersetzen.

Kann/will ich mir nicht leisten, es geht um 10 TB. Jetzt probiere ich zuerst wie es mit 1 SSD wird. Ich filme nur neuerdings mit mehreren Kameras und da ist die Bearbeitung besonders zäh.
 
Du kannst ja nach der Bearbeitung das fertige Video auf die Archiv-HDD kopieren, dann hast du die SSDs wieder frei fürs nächste Projekt. Erfahrungsgemäß erstellt man ja das Video immer mehrere Male und verändert jedes Mal noch was, bis es dann wirklich fertig ist, und die ganzen Bearbeitungsschritte wären mit SSDs sicher schneller abgehakt. Ich würde die SSDs also nur als Arbeitslaufwerke sehen, nicht als Archiv. Dass sie als Archiv zu teuer sind, ist klar, das wird sich erst in einigen Jahren ändern.
 
Du kannst ja nach der Bearbeitung das fertige Video auf die Archiv-HDD kopieren, dann hast du die SSDs wieder frei fürs nächste Projekt.

Genauso ist es gedacht, hatte ich früher auch schon einmal angedeutet und dafür reicht mir erst mal 1 SSD. Problem ist dabei, dass kdenlive ziemlich ekelig ist, wenn Pfade geändert werden. Solange die Dateiname der Originale aber nicht geändert werden, sollte man das automaisch durch Dateisuche ändern können. Das muss ich mir in der Praxis im Detail ansehen.

Ich bin aber noch immer nicht ganz sicher, ob die Sandisk die richtige SSD ist. Wenn die in einem Windows-PC zum FW-Update verbaut werden muss, dann scheidet sie aus. Das ist eine SSD für ein reines Linux-System. War schon beim Blu-Ray-Brenner ziemlcih umständlich mit dem FW-Update, ging nur an einem Windows-PC.
Ergänzung ()

Zurück zum Start. Welche Hersteller erlauben es einen bootfähigen USB-Stick für das Firmware-Update der SSD zu erstellen _ohne_ dass die SSD verbaut sein muss. Sandisk scheidet schon mal aus, Patriot auch. Bei Samsung könnte es klappen, da kann man ein ISO runterladen, ebenso bei Crucial.

Mit Crucial gibt es unter Linux Probleme, wie oben diskutiert und die Samsung SSD 840 PRO 256GB (MZ-7PD256BW) kostet in etwa das Doppelte der Crucial.
 
Zuletzt bearbeitet:
Wie siehst du die Plextor im Vergleich zur Samsung SSD 840 EVO 250GB (MZ-7TE250BW) ab €104,99 https://www.computerbase.de/2013-09/samsung-ssd-840-evo-test/ Die Samsung hat ja eine spezielle Cache-Technik und ob ich die beim Video-Rendern ausschöpfe, ist mir nicht klar, da ich keine Angabe für die 250G-Variante gefunden habe.

Edit: Wenn sich das Turbowrite-Puffer nennt, dann wären es 3G.

Es gibt auch eine Plextor M6S 256GB, SATA 6Gb/s (PX-256M6S) ab €123,75, das wäre vom Preis auch ok.
 
Zuletzt bearbeitet:
Die 840 Evo 250GB hat 3GB TurboWrite Cache und sollte danach mit 250MB/s sequentiell schreiben. Für deine Zwecke dürften auch die 250MB/s noch locker reichen, 25mbps (Megabit pro Sekunde) sind ja nur etwa 3MB/s und selbst bei 4 oder 5 Streams kommt man da noch lange nicht hin.
 
Gerade habe ich herausgefunden, dass es bei Sandisk doch ISOs gibt, ist aber chaotisch. Bin schon gespannt was bei http://forums.sandisk.com/t5/SanDisk-Extreme-SSD/Firmware-Update-unter-Linux/td-p/327656 geantwortet wird. Warum die FW-Updates so verstecken, soll einer verstehen. Man findet zB ein ISO, wenn man nach "SanDisk Extreme SSD Firmware Version R211, manueller ISO Download für MAC, Linux und PC" sucht, aber für welche SSDs dieses ISO gültig ist, darf man raten. Man kann das ja nicht so einfach probieren, falsche FW und das Teil ist tot.
 
Die Windows-Updates sind halt für die Mehrzahl der Nutzer am komfortabelsten, dabei allerdings am unsichersten und für alle, die kein Windows nutzen, unbrauchbar. ISOs sind sicher, universell, aber leider für viele überfordernd. Wobei sich schon die Frage stellt, wer überhaupt ein Firmware-Update macht. Der Nutzerkreis verengt sich sicher automatisch auf diejenigen, die auch mit einer ISO zurecht kommen.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben