Schreibcache auf diesem Gerät aktivieren geht mit Samsung SSD830 nicht?

[Blackpitty]

Hallo,

ich habe meine 1 Jahr alte Samsung SSD 830 128GB nun in mein Dell XPS M 1530 gebaut, welches ich 2008 kaufte.

Nun ist alles installiert(Win7) und funktioniert, doch im Gerätemanager unter Laufwerke und Eigenschaften der SSD lässt sich bei Richtlinien der Punkt:

Schreibcache auf diesem Gerät aktivieren


nicht auswählen.
Darunter ist ein großes gelbes Dreieck mit Ausrufezeichen, daneben steht: Die Schreibcacheeinstellung dieses Geräts darf nicht geändert werden

Wenn ich Schreibcache auf diesem Gerät aktivieren doch anklicke und auf ok gehe kommt diese Fehlermeldung:

Diese Funktion oder das Ändern der Einstellung wird von dem Gerät möglicherweise nicht unterstützt.



Woran liegt das nun? Vorher im Desktop Pc war das angehakt, genauso nun auch die Samsung 840 Evo im Desktop en Haken schon hatte

[Zafi]

1. Prüf mal im BIOS/UEFI ob deine 830 als Hot-Plug eingetragen ist.

2. Prüf mal im BIOS/UEFI ob sie mit AHCI läuft oder im IDE-Mode.

3. Sind die Chipsatz-Treiber beziehungsweise die AHCI-Treiber installiert?

[Blackpitty]

1:kann ich nirgends sehen und oder einstellen, außer ATA oder AHCI kann ich HDD Mäßig nichts ändern im einfach gehaltenen XPS M1530 Bios

2:habe auf AHCI umgestellt vor der Installation von Win 7

3:Chipsatz hatte ich die neuesten von Dell für Vista 64Bit geladen und im Kompatibilitätsmodus installiert, AHCI brauch ich doch keinen etra Treiber bei Win 7 oder? In der Registry steht MSAHCI auf 0 bei dem Punkt start, sprich es ist an

[Zafi]

3. Wirklich brauchen tust du ihn nicht, zumal die Samsung SSDs recht gut mit dem MS AHCI-Treiber laufen. Ich würde aber dennoch den Intel AHCI auf einem Intel System verwenden. Den neuesten findest du hier. (https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=23060&ProdId=2101&lang=eng&OSVersion=Windows%207%20%20*&DownloadType=Drivers)

[Blackpitty]

danke, leider kommt wenn ich ihn installieren will die Fehlermeldung:

Das Setup wurde Aufgrund des folgenden Fehlers vorzeitig beenedet:

Diese Plattform wird nicht unterstützt

:(

[Micha80]

Versuch mal den Intel® Matrix-Storage-Manager (https://downloadcenter.intel.com/Detail_Desc.aspx?lang=deu&DwnldID=17882).

[Coda]

Das ist zu deinem Eigenschutz. Mit Schreibcache ohne Batterie-Backup kannst du deine Daten auch direkt nach /dev/null speichern.

[Zafi]

Das ist zu deinem Eigenschutz. Mit Schreibcache ohne Batterie-Backup kannst du deine Daten auch direkt nach /dev/null speichern.

Also dass ist etwas übertrieben. Standardmäßig ist der Schreibcache für Systemlaufwerke aktiviert. Und wir alle haben sicherlich schon genügend BlueScreens erlebt, die unterm Strich keinerlei Auswirkungen hatten.

[Gast]

Also dass ist etwas übertrieben.
Nein, Schreibcache ohne entsprechende Absicherung (Batterie oder Superkondensator) kann bei wichtigen Daten wirklich böse enden...
Da denkt die Applikation, die Daten wären schon erfolgreich auf den Datenträger geschrieben, dabei liegen sie in Wirklichkeit nur irgendwo im RAM rum; wenn jetzt (aus welchem Grund auch immer) kurz der Strom ausfällt sind die Daten für immer verloren, obwohl die Applikation sie "erfolgreich" auf die HDD geschrieben hat.

[Zafi]

Nein, Schreibcache ohne entsprechende Absicherung (Batterie oder Superkondensator) kann bei wichtigen Daten wirklich böse enden...
Da denkt die Applikation, die Daten wären schon erfolgreich auf den Datenträger geschrieben, dabei liegen sie in Wirklichkeit nur irgendwo im RAM rum; wenn jetzt (aus welchem Grund auch immer) kurz der Strom ausfällt sind die Daten für immer verloren, obwohl die Applikation sie "erfolgreich" auf die HDD geschrieben hat.

Nochmal: Das ist falsch. Das Journaling fungiert genau dazu, um den Datenverlust des Schreibcaches zu verhindert. Als ob dies nicht genügen würde, arbeiten die Dateisysteme ab EXT3 und ab NTFS/Vista mit kompletten Journaling-Transaktionen. Und bieten damit eine noch viel sichere Methode der Datenwiederherstellung. Dabei wird das Dateisystem erst geändert, wenn sichergestellt ist, dass auch der letzte Bit einer kompletten Transaktion tatsächlich geschrieben wurde (z.B. beim Kopieren von 1000 Dateien auf einmal).

Die einzigen Daten die du verlieren kannst, sind Daten die "noch nie" gespeichert wurden. Also zum Beispiel ein gerade erst erstelltes Word-Dokument, dass gerade ein paar Sekunden alt ist, und von Word noch gar nicht temp-gesichert wurde. Falls du also tatsächlich fürchtest, die Arbeit der letzten paar Sekunden zu verlieren (was ja für manche Firmen auch fatal sein kann, z.B. Lotto-Gesellschaft, Banken, Versicherungen oder Geheimdienste), dann lohnt sich dafür sicher eine USV. Ansonsten ist jegliche Panikmache in der Hinsicht übertrieben. Denn wie schon gesagt, der Schreibcache wird von Windows auf allen Systemplatten automatisch aktiviert. Würde nach einem einfachen Blue-Screen tatsächlich so ein Supergau drohen, wie du ihn beschreibst (zumal mittlerweile der Schreibcache vieler Laufwerke mehrere GB umfasst), dann wäre der Aufschrei in den Foren deutlich zu hören.

[Gast]

Das Journaling fungiert genau dazu, um den Datenverlust des Schreibcaches zu verhindert.
Nein, das Journaling stellt nur die Konsistenz des Dateisystems sicher, nicht die konsistenz der Daten!
Die "Lösung" des Problems stellt wie bereits erwähnt entweder das komplette deaktivieren des Schreib-Caches oder die Verwendung eines Hardware-Caches mit Notstromversorgung dar, wie er in jedem modernen Storagesystem oder RAID-Controller vorhanden ist.

[joe kongo]

Kann man beide Dinge trennen ?

[Zafi]

Nein, das Journaling stellt nur die Konsistenz des Dateisystems sicher, nicht die konsistenz der Daten!

Mal abgesehen davon, dass auch dies nicht stimmt, ist es gar nicht unser Thema.

Thema ist, das einige Leute glauben, dass kopierte Daten verloren gehen könnten, wenn der Cache zu groß ist. Weil sie meinen, dass das Journaling und die Daten gemeinsam im Cache landen. Was aber nicht der Fall ist, weil das System die Kontrolle über den Cache hat und die Datenübertragung nicht veranlasst, solange das Journaling noch im Cache liegt.

[Gast]

Kann man beide Dinge trennen ?
Ja. Theoretisch könnte man natürlich auch Journaling für die eigentlichen Nutzdaten betreiben, aber das machen die Dateisysteme, von denen wir hier reden, nicht.

Mal abgesehen davon, dass auch dies nicht stimmt, ist es gar nicht unser Thema.
2x Doch.

Thema ist, das einige Leute glauben, dass kopierte Daten verloren gehen könnten, wenn der Cache zu groß ist.
Nein, dieses neue "Thema" existiert nur in deinem Kopf.

Weil sie meinen, dass das Journaling und die Daten gemeinsam im Cache landen. Was aber nicht der Fall ist, weil das System die Kontrolle über den Cache hat und die Datenübertragung nicht veranlasst, solange das Journaling noch im Cache liegt.
Du wirfst hier wild Begriffe durcheinander, deren Bedeutung du anscheinend nicht verstehst.
"das Journaling" kann gar nicht im Cache landen, da dieser Begriff nur das führen eines "Journals" (das meinst du wahrscheinlich) beschreibt.
Und was soll das "System" sein, von dem du redest? Das OS kann einen eigenen Schreib-Cache (im RAM) verwalten, der RAID Controller (sofern vorhanden) kann einen eigenen Cache (im eigenen RAM) halten und die HDD/SDD selber kann nochmals einen Cache besitzen.
Alle diese Caches sind bei Nutzung und unzureichender Absicherung ein potentielles Risiko Daten zu verlieren und wirklich Kontrollieren kann jede dieser Komponenten nur den jeweils eigenen Cache. Aus diesem Grund wird ein RAID-Controller auch standardmäßig alle angeschlossenen Platten anweisen, ihren internen Cache zu deaktivieren!

[Zafi]

Lies dir den Thread nochmal durch. Coda hat den TS gewarnt, dass ein Schreibcache ohne Batterie-Backup bei Ausfall zu einem sofortigem Datenverlust führt. Das ist das Thema.

Hier ein Auszug aus dem Technet, der dich interessieren dürfte: "NTFS guarantees that the log records containing the metadata operations of the transaction are written to disk before the metadata that is modified in the transaction is written to disk. After NTFS updates the cache, NTFS commits the transaction by recording in the cached log file that the transaction is complete. After the cached log file is flushed to disk, all committed transactions are guaranteed to be completed, even if the system fails before the changes are written to disk."

Daraus sollte ersichtlich sein, dass schonmal der Schreibcache (der Arbeitsspeicher des Computers) für das Journaling kein Problem darstellt. Und genau um diesen geht es hier (siehe Thread-Titel).

Und nochmal zur Erinnerung hier die Reihenfolge.

1. TS will wissen wie er den Windows-Schreibcache für seine SSD aktivieren kann.
2. Dem TS wird abgeraten dies zu tun, weil dies bei Ausfall zu sofortigem Datenverlust führen soll.
3. Und nun stellt sich heraus, dass dem nicht der Fall ist, weil das NTFS-Journaling den Windows-Schreibcache berücksichtigt.

Was das jetzt mit dem Schreibcache des Laufwerks zu tun haben soll oder mit irgendeinem dubiosen RAID-Controller-Schreibcache, den du da aus dem Ärmel ziehst und den der TS garnicht verwendet, verstehe ich nicht. Denn das ist hier alles nicht das Thema. Es geht hier um den Windows-eigenen-Schreibcache !!!

[Coda]

Journaling gibt's nur für Metadaten bei NTFS. Der Schreibcache kann ziemlich alte Daten enthalten, ich würde echt davon abraten:

http://blogs.msdn.com/b/oldnewthing/archive/2013/04/16/10411267.aspx

[Zafi]

Der Link bezieht sich auf das Erzwingen der Cache-Leerung und dass man diese nicht abschalten sollte, da es dann passieren kann, dass das Journal und die Daten gemeinsam im Cache liegen (auch Windows warnt davor). Standardmäßig ist diese Funktion aber eingeschaltet, somit besteht also keine Gefahr für die Daten. Zumindest nicht durch den Windows-Schreibcache.