News Seagates Archive HDD mit 8 TB im Handel gelistet

[Limit]

Das Problem ist aber wenn, dann nicht der Durchsatz (das wäre es bei Streaming, etwas wofür Seagate die Platte auch als nicht geeignet kennzeichnet), es ist ggf. die zu lange Antwortzeit und wer kennt den schon den Timeout seines NAS und kann erkennen, ob es nur daran lag?

Du hast immer noch nicht erklärt, warum das Timeout bei der Archive-Platte greifen sollte, bei anderen Platten (bei entsprechend höherer Last) aber nicht.

Nur das Betriebssystem der normalen HDD auch TRIM Befehle schicken. Der fängt kein Flag ab, das muss er aus den Drive Ident Daten erkennen und es ist auch nicht der Treiber, sondern wenn denn das Betriebssystem (der Treiber weiß ja nichts von Dateien, nur das Betriebssystem), aber das hast Du sicher so gemeint.

Für das schicken des TRIM-Befehls ist das Dateisystem zuständig. Damit es das tut, muss man unter Linux z.B. entweder eine entsprechende mount Option setzen (discard) oder ein ein Program (fstrim) benutzen. In beiden Fällen, frägt das Dateisystem dann beim entsprechenden Treiber nach, ob TRIM überhaupt unterstützt wird. Der Treiber wiederum frägt bereits beim initialisieren das Laufwerk, ob es TRIM unterstützt. Wenn das Laufwerk (egal ob SSD oder HDD) dem Treiber TRIM-Unterstützung signalisiert, interessiert es im weiteren weder den Treiber noch das Dateisystem ob es eine SSD oder HDD ist.

Auch Blödsinn, Windows sendet z.B. keine TRIM Befehle an SAS oder RAID Controller und auch nicht für USB, auch wenn die SSD daran angeben TRIM zu unterstützen.

Zumindest für Windows 8.1 und Windows Server 2012 R2 kann Windows TRIM-Befehle auch an SAS-Laufwerke schicken laut msdn. Bei USB funktioniert TRIM nicht, weil das gewöhnlich benutzte Protokoll (USB Mass Storage Bulk-Only Transport) nur einen Teil der ATA Befehle unterstützt. Deswegen funktionieren z.B. auch SMART oder NCQ nicht. Mit dem neueren UASP-Protokoll (USB-Attached-SCSI) hingegen ist das überhaupt kein Problem mehr.
Wie es bei HW-RAID-Controllern aussieht, weiß ich nicht. Bei Intel's Fake-RAID ist TRIM zumindest bei RAID0/1 möglich. Bei Software-RAID unter Linux ist das ähnlich. Bei anderen RAID-Modi ist die Implementierung hingegen deutlich schwieriger, weil es ja kein 1:1 Mapping mehr zwischen Sektoren auf den RAID-Volumes und den darunter liegenden Disks gibt. Prinzipiell möglich wäre es, es wäre aber wohl recht kompliziert zu implementieren.

 

[Holt]

2 der Seagate Festplatten verreckten während ich meinen damaligen PC noch in Betrieb hatte, vom einen auf den andern Tag.

Das klingt aber so, als hättest Du entweder deren Zustand nicht geprüft oder, wenn beide am gleichen Tag starben, dass ein externes Ereignis sie gekillt hat.

Die Dritte funktioniert noch, bzw wird noch erkannt, jedoch ist sie unfassbar langsam und macht sehr sehr komische laute Geräusche, also vmtl auch kaputt.

Dann poste doch mal den Screen von CrystalDiskInfo (die Portable Standard Edition reicht und ist frei von Werbung) in dem dafür vorgesehenen Sammelthread, ziehe aber bitte das Fenster soweit auf, dass alle Attribute und auch die Rohwerte vollständig sichtbar sind.

Meine Laptopfestplatte von Seagate ist mir ebenfalls vor knapp 3 Monaten verreckt, mitsamt allen Daten. Die war nichtmal 2 Jahre alt.

Wie wurde die behandelt und warum gab es kein Backup? Gerade in Laptops die wirklich mobil genutzt werden, werden die Platten oft viel zu harten Stößen ausgesetzt und das können die gar nicht ab, weder die von Seagate noch die anderer Hersteller.

Trotzdem sind es bei der Anzahl Einzelschicksale und statistisch wenig aussagekräftig. Kaufe Dir halt HDDs anderer Hersteller, wenn Du Dich damit wohler fühlst. Ich hatte noch mit keiner Seagate Probleme und Du wirst sicher auch andere finden, denn es so geht aber die WD Platten schon Ärger hatten, was genauso wenig aussagt.

Du hast immer noch nicht erklärt, warum das Timeout bei der Archive-Platte greifen sollte, bei anderen Platten (bei entsprechend höherer Last) aber nicht.

Doch das haben ich, Thema "Write Amplification", weil die SMR Platten spätestens dann beim Schreiben lahmer sein müssen, wenn der Cache nicht mehr greift und sie wirklich beim Schreiben einer Spur die außen liegt erst die Daten der halb darüber liegenden Spuren lesen und dann später auch wieder zurückschreiben müssen.

Für das schicken des TRIM-Befehls ist das Dateisystem zuständig. Damit es das tut, muss man unter Linux z.B. entweder eine entsprechende mount Option setzen (discard) oder ein ein Program (fstrim) benutzen.

Unter Linux ja, wobei ich mir mit dem Nachfragen nicht sicher bin (hast Du Belege dafür?), aber unter Windows sieht das anders aus, da kann man es nicht für die Platten einzeln einstellen.

Deswegen funktionieren z.B. auch SMART oder NCQ nicht. Mit dem neueren UASP-Protokoll (USB-Attached-SCSI) hingegen ist das überhaupt kein Problem mehr.

S.M.A.R.T. Wird auch von Bulk unterstützt und TRIM kann bei UASP nicht gehen, weil es ein ATA und kein SCSI Befehl ist, das SCSI Euqivalent heißt Unmap, welches Windows auch an SAS keine TRIM Befehle schickt, ansonsten die Quelle bei MSDN bitte.

Wie es bei HW-RAID-Controllern aussieht, weiß ich nicht. Bei Intel's Fake-RAID ist TRIM zumindest bei RAID0/1 möglich.

Das es am Intel Controller geht, zumindest den neuren mit passendem OROM und Treiber, ist bekannt und es geht sogar am Marvell 9230, wie Du in diesem Thread bei planet3dnow sehen kannst, aber der Marvell verwaltet das RAID selbst und Windows sieht das RAID nur als eine normale AHCI Platte, weshalb es mit dem Microsoft AHCI Treiber geht, Intels Fake RAID dürfte es ähnlich handhaben. Bei HW-RAID Controller gibt es ein paar Exoten, einige PCIe SSDs die auf normalen SATA SSD Controllern basieren nuzen diese, aber die üblichen Modelle von LSI oder Adaptec können es meines Wissens nicht bzw. bekommen wohl Windows keine entsprechenden Befehle geschickt.

Bei anderen RAID-Modi ist die Implementierung hingegen deutlich schwieriger, weil es ja kein 1:1 Mapping mehr zwischen Sektoren auf den RAID-Volumes und den darunter liegenden Disks gibt. Prinzipiell möglich wäre es, es wäre aber wohl recht kompliziert zu implementieren.

Das hat damit nichts zu tun, man braucht kein 1:1 Mapping, das gibt es bei einem RAID 0 auch nicht und TRIM geht damit z.B. bei Intel sehr wohl. Der Controller bzw. die RAID SW muss ja auch beim Lesen oder Schreiben auch die globalen LBAs des RAID in lokale LBAs der Platten umrechnen und dann für jede Platte eigene, neue Befehle erzeugen mit den entsprechend angepassten lokalen Adressen. Das Problem bei allen RAIDs mit Parity ist die Datenkonsistenz. Die Ausführungszeit ist bei TRIM nicht genormt und schwank auch zwischen den SSDs und ebenso ist nicht definiert, was die Platten zurückgeben, wenn getrimmt LBAs ausgelesen werden. Außerdem scheinen SSDs TRIM Befehle auch schon mal nicht auszuführen, wenn sie gerade massiv beschäftigt sind, vermutlich um zu verhindern das durch NCQ ein TRIM Befehl in der Reihenfolge dann hinter einen Schreibbefehl kommt der die gleichen LBAs betrfft (Crucials m550 hatte da Probleme, was aber nur unter bestimmten Linux Versionen auftrat und mit der FW MU02 wohl behoben wurde). Bei einer Konsistenzprüfung des RAIDs (Scrubbing) wäre dann die Daten nicht konsisten, wenn sich nicht alle SSDs syncon verhalten und was soll das RAID dann machen? Es weiß ja selbst nicht, ob dieser Bereich nun mit Daten belegt ist oder nicht. Das Problem wäre nur mit einem RAID welches das Filesystem selbst verwaltet, wie ZFS, zu beheben.

 

[ranx]

So interessant diese Diskussion ist - ich möchte doch mal eine inzwischen fast Off-Topic-anmutende Frage stellen:

Hat jemand schon eine der besagten Platten geliefert bekommen und kann etwas dazu sagen?

 

[Limit]

Unter Linux ja, wobei ich mir mit dem Nachfragen nicht sicher bin (hast Du Belege dafür?)

Kurz zusammengefasst funktioniert TRIM/UNMAP unter Linux ungefähr so: Beim Initialisieren wird für jedes Block-Device eine request-queue eingerichtet und entsprechend der Rückmeldung vom Gerät bestimmte Flags gesetzt, u.A. QUEUE_FLAG_DISCARD. Das Dateisystem benutzt die blk_queue_discard() Funktion um herauszufinden, ob das Gerät TRIM/UNMAP unterstützt und falls ja benutzt es blkdev_issue_discard(). Das veranlasst den entsprechenden Treiber ein TRIM/UNMAP request an das Gerät zu schicken. Diese Funktionen sind in der blkdev.h definiert.

S.M.A.R.T. Wird auch von Bulk unterstützt

Ich habe noch einmal etwas nachgelesen. Prinzipiell ist es möglich, nur einige Bridge-Chips haben es nicht implementiert.

Some USB mass-storage interfaces are generic, providing basic read-write commands. Although this works well for basic data transfer with hard-drive-based devices, there is no simple way to send advanced, device-specific commands to USB mass-storage devices

und TRIM kann bei UASP nicht gehen, weil es ein ATA und kein SCSI Befehl ist, das SCSI Euqivalent heißt Unmap, welches Windows auch an SAS keine TRIM Befehle schickt, ansonsten die Quelle bei MSDN bitte.

Das mag richtig sein, allerdings wird TRIM, UNMAP und DISCARD häufig synonym verwendet, da es im Endeffekt nur verschiedene Namen für die gleiche Sache sind. Microsoft spricht z.B. hier von TRIM in Verbindung mit SAS-SSDs. Mit Ausnahme der Low-Level-Treibern werden auch unter Linux SCSI und SATA-Devices seit einiger Zeit vollständig gleich behandelt. TRIM (ATA) und UNMAP (SCSI) heißen im IO-Subsystem dann einfach DISCARD. Unterschieden wird dann erst auf aller unterster Ebene.

Das hat damit nichts zu tun, man braucht kein 1:1 Mapping, das gibt es bei einem RAID 0 auch nicht und TRIM geht damit z.B. bei Intel sehr wohl.

Natürlich geht es, es ist eben nur komplexer. Deswegen war bei TRIM unter Linux Software-RAID zuerst nur bei RAID1 möglich, anschließend folgte dann RAID0 und auf TRIM-Unterstützung bei anderen Levels wartet man, glaube ich, heute noch.

und ebenso ist nicht definiert, was die Platten zurückgeben, wenn getrimmt LBAs ausgelesen werden.

Da hatten die Igenieure wohl nur Dateisysteme im Kopf. Die sollten ja tunlichst keine LBAs auslesen, die sie vorher schon freigegeben haben.

Außerdem scheinen SSDs TRIM Befehle auch schon mal nicht auszuführen, wenn sie gerade massiv beschäftigt sind

Was ja durchaus sinnvoll ist um die Response-Time niedrig zu halten. Der GC springt ja z.B. auch nur dann an, wenn die Platte nicht ausgelastet ist.

vermutlich um zu verhindern das durch NCQ ein TRIM Befehl in der Reihenfolge dann hinter einen Schreibbefehl kommt der die gleichen LBAs betrfft

Wenn NCQ TRIM-Befehle hinter einen Schreibbefehl mit der gleichen LBA sortiert ist das ein Bug. Im Prinzip sollte NCQ TRIMs wie eine Schreiboperationen behandeln.

Bei einer Konsistenzprüfung des RAIDs (Scrubbing) wäre dann die Daten nicht konsisten, wenn sich nicht alle SSDs syncon verhalten und was soll das RAID dann machen? Es weiß ja selbst nicht, ob dieser Bereich nun mit Daten belegt ist oder nicht. Das Problem wäre nur mit einem RAID welches das Filesystem selbst verwaltet, wie ZFS, zu beheben.

Das ist ein interessanter Punkt. Dateisysteme wie ZFS und btrfs haben das Problem nicht, das ist klar. Ein HW-RAID-Controller müsste hingegen mitloggen, welche Blöcke beschrieben wurden und welche noch frei sind bzw. per TRIM wieder freigegeben wurden. Das wäre vermutlich möglich, aber afaik macht das keiner.
Es kann sein, das die folgende Idee Unsinn ist, aber würde eine Sequenz write-barrier->sync->write-barrier->scrub das Problem nicht lösen? Die erste write-barrier sorgt dafür, dass keine anderen Schreiboperationen ausgeführt werden, bevor nicht alle noch ausstehenden Schreiboperationen durchgeführt wurden. Die zweite write-barrier sorgt dafür, dass keine anderen Schreiboperationen ausgeführt werden solange nicht alle Puffer geleert wurden. Das Scrubbing müsste dann nicht extra geschützt werden, da NCQ keine Schreiboperationen vor eine Leseoperation auf den gleichen Block schiebt.

So interessant diese Diskussion ist - ich möchte doch mal eine inzwischen fast Off-Topic-anmutende Frage stellen:

Hat jemand schon eine der besagten Platten geliefert bekommen und kann etwas dazu sagen?

Ich noch nicht, ich fahre erst einmal in Urlaub und bestell mir erst anschließend eine. Solange dürft ihr Versuchskaninchen spielen.

 

[AW312]

Hat jemand schon eine der besagten Platten geliefert bekommen und kann etwas dazu sagen?

Ist bestellt, aber noch nicht geliefert.

 

[Holt]

Das veranlasst den entsprechenden Treiber ein TRIM/UNMAP request an das Gerät zu schicken.

Nochmal, das kann der Treiber nicht, der kennt das Filesystem nicht weil er eine Stufe tiefer liegt, die Befehle müssten vom Betriebssystem kommen. Nur das kann beim Löschen einer Datei nachsehen welche LBAs diese belegt hat (wie es das auch beim Lesen der Datei macht) und dann für diese LBAs eben TRIM Befehle (statt Lesebefehlen wenn man die Datei lesen würde) zu schicken. Der Treiber bekommt dann nur die Aufforderung der Platte die passenden Befehle mit den LBAs zu schicken, die muss er dann ggf. auch noch aufteilen, weil jede Platte ein eigenes Limit hat wie viele LBAs mit einem Befehl adressiert weren können, steht auch in den Drive Ident Daten. Die üblicherweise heute verwendeten ATA Befehle erlauben bis zu 2^16 LBAs mit einem Befehl zu adressieren.

Prinzipiell ist es möglich, nur einige Bridge-Chips haben es nicht implementiert.

Das ist gerade bei alten Chips leider wahr, die neuren können es i.d.R. aber schon.

Da hatten die Igenieure wohl nur Dateisysteme im Kopf. Die sollten ja tunlichst keine LBAs auslesen, die sie vorher schon freigegeben haben.

Das wohl weniger, die haben sie da wohl an den HDDs orientiert und da weiß man auch nie, was in einem Sektor steht der nicht explicit beschrieben wurde und das wäre nach einem Schnellformat eben irgendetwas von irgendwelchen alten Daten. Nur neue Platten liefern gewöhnlich 00 zurück, so wie es auch bei SSDs üblich ist. Das kann man mit dem Tool TrimCheck prüfen und dann sieht man auch, dass es unterschiedlich lange dauert bis die SSDs wirklich 00 statt der Daten liefern.

Was ja durchaus sinnvoll ist um die Response-Time niedrig zu halten. Der GC springt ja z.B. auch nur dann an, wenn die Platte nicht ausgelastet ist.

Was Du meinst ist die Idle-GC, die GC ist bei jeder SSDs vorhanden und wenn es keine freien Pages mehr gibt, muss die auch während der Schreibvorgänge eingreifen, was dann zu den Einbrüche bei den Performance Consistancy Test führt, wie sie z.B. Anandtech in SSD Reviews durchführt.

Wenn NCQ TRIM-Befehle hinter einen Schreibbefehl mit der gleichen LBA sortiert ist das ein Bug. Im Prinzip sollte NCQ TRIMs wie eine Schreiboperationen behandeln.

Kann man so sehen, aber wenn man die SSD auf die besten Performance in Benchmarks auslegen will, dann kann es auch Sinn machen die TRIM Befehl nach hinten zu schieben oder ganz unter den Tisch fallen zu lassen. Es wird schon einen Grund haben warum Microsoft bei Win8 dann die Optimierung der SSD eingeführt hat, was dem fstrim unter Linux entspricht, also ein Batch TRIM auf alle als unbelegt marktierten LBAs auslöst.

Ein HW-RAID-Controller müsste hingegen mitloggen, welche Blöcke beschrieben wurden und welche noch frei sind bzw. per TRIM wieder freigegeben wurden. Das wäre vermutlich möglich, aber afaik macht das keiner.

Das wäre auch ein gewaltiger Aufwand, denn so ein RAID hat eine gewaltigen Menge an LBAs und damit gäbe das gigantische Datenmenge.

Es kann sein, das die folgende Idee Unsinn ist, aber würde eine Sequenz write-barrier->sync->write-barrier->scrub das Problem nicht lösen?

Nein, da ja das Problem die Verzögerung der Ausführung der TRIM Befehle innerhalb der SSD ist, die passiert erst Sekunden bis Minuten nachdem die Befehle geschickt wurden und die SSD bestätigt die Ausführung der Befehle auch nicht, der RAID Controller wird also niemals erfahren, wann der SSD Controller nun schon 00 für getrimmt LBAs liefert und wann noch die alten Daten und selbst wenn, er SSD Controller könnte auch 0xFF liefern, es ist ja nicht definiert was er dann liefern soll.

Bei einer HDD mit SMR die auch Caches setzt wäre das noch wüster, da müsste der Controller der Platte getrimmt LBAs physikalisch überschrieben, was bzgl. Performance und Workload totaler Unsinn wäre. Hat er aber einen Cache, egal ob NAND oder besonderen Bereiche auf der Disk, so wird er diesen natürlich freigeben und dann würde man auf einem Teil der getrimmten LBAs die noch im Cache waren und nicht an ihren Platz geschrieben waren bevor zu getrimmt wurden noch ältere Daten finden und die Parity würde gar nicht passen.

Man stelle sich außerdem die Datenmenge vor um zu verwalten welche LBAs getrimmt wurden, dass würde bei einer 8TB Platten dann einige GB ausmachen und einen hohen Aufwand im Controller bedeuten. TRIM für HDDs mit SMR halte ich also für wenig wahrscheinlich, auch wenn es gewisse Vorteile bieten würde.

fahre erst einmal in Urlaub

Schönen Urlaub!

 

[DunklerRabe]

So interessant diese Diskussion ist - ich möchte doch mal eine inzwischen fast Off-Topic-anmutende Frage stellen:

Hat jemand schon eine der besagten Platten geliefert bekommen und kann etwas dazu sagen?

Ist wirklich interessant zu verfolgen, nur der Erkenntnisgewinn lässt noch auf sich warten

Und nein, aber ich hab ein Auge auf die Preisentwicklung und werde demnächst dann mal zuschlagen!

 

[Limit]

Nochmal, das kann der Treiber nicht, der kennt das Filesystem nicht weil er eine Stufe tiefer liegt, die Befehle müssten vom Betriebssystem kommen.

Da haben wir aneinander vorbei geredet. Natürlich wird geht das TRIM vom Dateisystem aus. Das benutzt eben diese blkdev_issue_discard() Funktion, die u.A. die betroffenen LBAs als Parameter mitbekommt. Mit diesen und noch einigen anderen Infos erzeugt der Treiber dann ein TRIM/UNMAP request und schickt das an das block-device.

Was Du meinst ist die Idle-GC

Jep, genau den meine ich.

Kann man so sehen, aber wenn man die SSD auf die besten Performance in Benchmarks auslegen will, dann kann es auch Sinn machen die TRIM Befehl nach hinten zu schieben oder ganz unter den Tisch fallen zu lassen.

Eine Festplatte kann einen TRIM-Befehl entweder ignorieren oder soweit nach hinten schieben solange es keine writes oder zumindest keine writes auf zu trimmende Blöcke gibt. Kommt so ein write bleibt ihr nur noch die Wahl entweder den TRIM-Befehl vorher auszuführen oder ihn komplett zu verwerfen. Tut sie das nicht, ist das ein Bug, der zur Datenkorruption führt.

Es wird schon einen Grund haben warum Microsoft bei Win8 dann die Optimierung der SSD eingeführt hat, was dem fstrim unter Linux entspricht, also ein Batch TRIM auf alle als unbelegt marktierten LBAs auslöst.

Das hat eindeutig Performance-Gründe. Notwendig für die Datenintegrität ist es nicht.

Das wäre auch ein gewaltiger Aufwand, denn so ein RAID hat eine gewaltigen Menge an LBAs und damit gäbe das gigantische Datenmenge.

Je nach Art der Daten und ihrer Fragmentierung könnten das in der Tat große Datenmengen werden, vgl. mit den Metadaten eines Dateisystems. Bei meinem 13TB btrfs Volume sind das z.B. etwa 9GB und darauf sind weder viele kleine Dateien drauf, noch sind die Daten stark fragmentiert.

Nein, da ja das Problem die Verzögerung der Ausführung der TRIM Befehle innerhalb der SSD ist, die passiert erst Sekunden bis Minuten nachdem die Befehle geschickt wurden.

Ein sync sollte die request-queue flushen und damit eigentlich auch evtl. noch nicht ausgeführte TRIMs.

und die SSD bestätigt die Ausführung der Befehle auch nicht

Ich weiß nicht, wie die SSD das verarbeitet, aber zumindest unter Linux kann man bei einem bio request die beiden flags sync und discard gemeinsam setzen. Ich sollte mal ausprobieren, was passiert, wenn man das macht.

der RAID Controller wird also niemals erfahren, wann der SSD Controller nun schon 00 für getrimmt LBAs liefert und wann noch die alten Daten und selbst wenn, er SSD Controller könnte auch 0xFF liefern, es ist ja nicht definiert was er dann liefern soll.

Ok, das ist dann wirklich ein Problem.

TRIM für HDDs mit SMR halte ich also für wenig wahrscheinlich, auch wenn es gewisse Vorteile bieten würde.

Die erste Generation wird es vielleicht nicht haben, aber spätestens wenn die SMR-Technik auch in Platten für andere Anwendungsbereiche benutzt werden soll, könnte ich es mir durchaus vorstellen.

Schönen Urlaub!

Danke, du bist wohl froh, dass du mich dann los bist

 

[Holt]

Tut sie das nicht, ist das ein Bug, der zur Datenkorruption führt.

Den gab es ja bei einigen Crucial SSD (m500 und m550 wenn ich mich nicht irre), der sollte aber gefixt sein und es fällt ja nur unter Linux auf, auch nur unter einigen Linux Systemen.

Das hat eindeutig Performance-Gründe. Notwendig für die Datenintegrität ist es nicht.

Das ist bei TRIM aber immer so, nur dürfte so ein Batch-TRIM eigentlich keinen Einfluss habe, wenn das TRIM Löschen der Dateien auch schon geschickt wurde, weil ja alle LBAs von gelöschten Dateien dann getrimmt wurden. Wurden LBAs dann wieder belegt, werden sie auch beim Batch-TRIM (also Windows Optimierung bzw. fstrim unter Linux) nicht mehr getrimmt, also sollten eigentlich immer nur schon getrimmt LBAs noch einmal getrimmt werden. Wenn immer alle SSDs alle TRIM Befehle beffolgen würden, wäre das komplett unnötig, aber Windows hat es trotzdem mit Win8 eingeführt.

Ein sync sollte die request-queue flushen und damit eigentlich auch evtl. noch nicht ausgeführte TRIMs.

Es gibt aber auch SSD und auch RAID Controller sync Befehle ignorieren, was auch in Ordung ist, wenn sie z.B. eine "Notstromversorgung" haben und in jedem Fall den Verlust der Daten im Schreibcache bei Stromausfall vermeiden können. Leider machen es auch SSDs die das nicht haben, z.B. die mit den Sandforce Controller aber auch die mit dem Barefoot 3. Da wird es dann sehr wahrscheinlich nicht funktionieren, bei den anderen müsste man das ausprobieren. Ein Test ob die SSD sync ignoriert geht unter Windows recht einfach indem man mit dem AS-SSD Benchmark bencht, einmal mit dieser Einstellung:



Und einmal nachdem man den Harken dort entfernt (und zumindest beim Systemlaufwerken) neu gebootet hat. An den 4k Schriebend Werte sollte man eine sehr deutlichen Unterschied sehen, die sind ohne Schreibcache meist bei wenigen MB/s.

Ich weiß nicht, wie die SSD das verarbeitet, aber zumindest unter Linux kann man bei einem bio request die beiden flags sync und discard gemeinsam setzen. Ich sollte mal ausprobieren, was passiert, wenn man das macht.

Dann mache aber vorher den Test ob die SSD die Sync fakt, denn wenn, dann ist der Test vermutlich auch nicht aussagekräftig.

Lass mich wissen wenn Du das getestet hast und auch wie Du den Test gestaltet hast und was dabei rausgekommen ist.

Die erste Generation wird es vielleicht nicht haben, aber spätestens wenn die SMR-Technik auch in Platten für andere Anwendungsbereiche benutzt werden soll, könnte ich es mir durchaus vorstellen.

Das ist denkbar, die Technik ist ja noch am Anfang, andererseits sehe ich da auch nur begrenzt Potential für weitere Steigerungen der Kapazität. Mal sehen wann HMR kommt.

Danke, du bist wohl froh, dass du mich dann los bist

Nein, die Diskussion mit Dir hat sich fruchtbarer entwickelt als ich das anfangs befürchtet habe. Den Urlaub hast Du jetzt auch verdient, war ja teils ein hartes Match

 

[hantolo]

Meine ist gestern angekommen. Die Gewinde an der Unterseite stehen weiter auseinander als üblich und so konnte ich sie auf der Festplattenschiene meines Fractal Design R3s nicht mit den vorgesehenen Öffnungen verschrauben. Ich konnte aber die Gummis der Schiene rausnehmen und in den Rand der Schiene schieben und da dann festschrauben. War ein wenig seltsam, aber hält. Unabhängig davon rumpelt zumindest meine Archive HDD. Wenn man sie anfasst, spürt man deutlich "Schläge" von innen. Unregelmäßig, aber zwei drei die Sekunde. Auch bei Nichtbenutzung der Festplatte. Und das überträgt sich auch aufs Gehäuse. Allerdings habe ich auch ein empfindliches Gehör.
Crystal Disk Info meldet keine Fehler, aber das Rumpeln ist mir nicht geheuer...

 

[johnripper]

Die Gewinde an der Unterseite stehen weiter auseinander als üblich und so konnte ich sie auf der Festplattenschiene meines Fractal Design R3s nicht mit den vorgesehenen Öffnungen verschrauben.

Etwa wie hier beschrieben?

 

[DunklerRabe]

Also das kann bzw. sollte nicht sein.

Es ist eine 3.5" Festplatte, das Format ist ja nicht umsonst ein Standard. Das sollte daher schon passen. Und das Gerumpel sollte ja auch nicht sein, womöglich hängt es aber jetzt mit der Art der Montage zusammen. Ich kann mir nicht vorstellen, dass das zum normalen Betrieb gehört.

Etwa wie hier beschrieben?

Ups!

 

[hantolo]

Ja. Genau wie im Link beschrieben...

Festplatte liegt aber gerade und fest auf, Rumpeln war schon die ganze Zeit vorhanden. Na gut, dann wohl als defekt zurückschicken.

 

[flickflack]

Hier ist ein Test der Platte.
Sie ist aktuell bei Mindfactory lagernd (5 Stk). Da im Test und auch von Seagate davon abgeraten wird, sie im NAS zu betreiben, werde ich sie mir nicht holen.

Zwischenfrage: Warum wird ausdrücklich davon abgeraten?
Mögliche AW: Weil es bei einem Rebuild / dem Ausbau mit weiteren Platten (von 2 auf 3+ Platten) im NAS zu erheblichen Schreibvorgängen kommt (Raid 1 zu Raid 5 - da muss ja quasi 50% neu geschrieben werden, plus Löschvorgänge auf den alten Platten)

Die Platte ist also wirklich nur als Datengrab zu gebrauchen.

 

[Cool Master]

Zwischenfrage: Warum wird ausdrücklich davon abgeraten?

Wurde doch schon geklärt erstens weil das nicht der EInsatzzweck ist und zweitens die Geschichte mit SMR

Btw. ich hab mir aktuell 5x5TB Red gekauft. Mit einer neuen Diskstation und verkauf meiner alten inkl. HDDs habe ich somit effektiv nur 86 € mehr ausgegeben als 4x6TB kaufen.

 

[flickflack]

Ja schade, 8TB pro Platte wäre schon was feines gewesen.

 

[Cool Master]

Ja sehe ich auch so aber es kann gerne jemand anders Beta Tester spielen ich mache es nicht

 

[Triversity]

Ob gewollt oder nicht, irgendjemand findet sich doch immer

 

[DunklerRabe]

Machs doch einfach, es spricht nicht viel dagegen. Wir hatten das vor einigen Tagen schonmal, meiner Meinung nach ist das äußerst unqualifiziert einfach davon abzuraten. Und außerdem, jetzt bitte mal genau darauf achten, WIRD VON SEAGATE NICHT DAVON ABGERATEN.

Archive HDDs are not intended for surveillance or NAS applications, and you may experience lower performance in these
environments. For these applications, Seagate NAS HDDs and Seagate Surveillance HDDs are suggested for better performance
and reliability

Erstens ist immernoch von Enterprise Use Cases auszugehen. Die angedachten Use Cases sind fordernder als NAS Betrieb zu Hause. Und zweitens haben das ja auch die Tests ergeben:

Bei Benchmarks fällt das auf: Eine fortlaufende Messung der Zugriffszeiten beim Schreiben mit H2benchw führte zunächst zu einem Ergebnis von 0,3 ms (Cache) beim Schreiben. Nach rund einer Minute stieg der Wert auf übliche 14 ms (Pufferzone) und nach einer Viertelstunde auf lahme 290 ms – da musste die Platte die Daten direkt in den SMR-Zonen ablegen. Beim sequenziellen Schreiben von Daten erreichte die Archive HDD v2 maximal gute 185 MByte/s, die Mittelwerte beim Lesen und Schreiben liegen bei rund 130 MByte/s.

Nutzt du dein NAS zu Hause so intensiv, dass das zum Problem wird oder du die Specs der Platte überschreitest? Vermutlich nicht, das würden nur die wenigsten. Und wenn nein, dann gibt es keinen Grund die Platte nicht zu nehmen.

 

[Cool Master]

Na ja abgesehen davon:

"Archive HDDs are not intended for surveillance or NAS applications".

Ich verstehe nicht warum du auf verderb und komm raus meinst die kann man auch als NAS HDD nutzen. Der Hersteller sagt man sollte es nicht machen und daran würde ich mich halten.

Das sie gehen werden bestreitet keiner! Man muss sich aber im klaren sein der Hersteller sagt, das die HDDs nicht für ein NAS sind und das die Leistung nachlässt also sind die Test von einer HDD irrelevant da in einem NAS ein RAID genutzt wird und da sehen die Zeiten sicherlich noch mal anders aus.