News Festplatten: Auch bei Seagate gibt es SMR als Überraschung

hRy schrieb:
Ich glaube hier im Forum hatte einer mal einen Screenshot der Betriebsstunden seiner Spinpoints gemacht ~ 50.000 Std!
2020-04-17 21_47_41-CrystalDiskInfo 8.1.0 Shizuku Edition x64.png

^^
Meine alten HDDs die ähnlich viel auf dem Lager haben werkeln inzwischen bei einem Freund da sie mir zu klein geworden sind. Bisher macht da keine anstalten auszufallen. Dauerbetrieb und gleichmäßige, günstige Temperaturen sind eben Festplattenschonend im gegenzug zu ständig ein/aus schalten.
Die verbleibende WD Red hat erst 44k Stunden rum. Also noch jugendlich aus sicht der 840pro
mgutt schrieb:
Du zeigst damit nur, dass sie normal schnell beschrieben werden kann, wenn keine Daten überschrieben werden müssen. Genau das packen SMR noch. Inkrementelle Backups auch kein Problem. Aber wehe du aktualisierst Daten oder verschiebst diese. zB ein Sync-Backup mit der Entfernung bereits gelöschter Dateien. Oder wenn ein inkrementelles Backup überalterte Sicherungen entfernt und das nächste inkrementelle Backup startet.
Also wer seine -Archiv- HDD für intensive schreibzugriffe nutzen will hat sowieso schon was falsch gemacht. Da ist doch klar dass die größere, sequentielle schreibaktionen mögen und alles andere eher ungünstig ist.
Natürlich muss man dazu wissen das unter der haube SMR genutzt wird.

Zur Geschwindigkeitsdiskussion ...
3 ST8000AS0002 in einem raid-z1, knapp 3,56 TB belegt, 9,irgendwas8 TB frei
cpu war beschäftigt (BOINC WCG auf 6 von 8 logischen kernen), gelegentlich leichter lesezugriff auf den pool da dort meine musik liegt. ist also keine 'sterile' testumgebung mit frischen oder leeren platten
root@deepspacewalrus:/mnt/archiv/test# zfs set compression=off archivpool
root@deepspacewalrus:/mnt/archiv/test# dd if=/dev/zero of=testfile status=progress bs=1M count=10k
10592714752 Bytes (11 GB, 9,9 GiB) kopiert, 27,0031 s, 392 MB/s
10240+0 Datensätze ein
10240+0 Datensätze aus
10737418240 Bytes (11 GB, 10 GiB) kopiert, 27,997 s, 384 MB/s
root@deepspacewalrus:/mnt/archiv/test# dd if=/dev/zero of=testfile status=progress bs=1M count=100k
107199070208 Bytes (107 GB, 100 GiB) kopiert, 317,003 s, 338 MB/s
102400+0 Datensätze ein
102400+0 Datensätze aus
107374182400 Bytes (107 GB, 100 GiB) kopiert, 317,507 s, 338 MB/s
root@deepspacewalrus:/mnt/archiv/test# dd if=/dev/zero of=testfile status=progress bs=1M count=1M
1099230609408 Bytes (1,1 TB, 1,0 TiB) kopiert, 3506 s, 314 MB/s
1048576+0 Datensätze ein
1048576+0 Datensätze aus
1099511627776 Bytes (1,1 TB, 1,0 TiB) kopiert, 3506,83 s, 314 MB/s
root@deepspacewalrus:/mnt/archiv/test# dd if=/dev/zero of=testfile status=progress bs=1M count=9M
7993353568256 Bytes (8,0 TB, 7,3 TiB) kopiert, 28947 s, 276 MB/s^C
Ja, ich war so doof strg+c zu drücken weil ich im tran noch in windows war. shame on me
aber was rauskommt ist dass die schreibrate auch bei großen mengen keinen knick auf 20 mb/s oder dergleichen macht
die hohen werte am anfang liegen am cache, zfs hat glaub ich 8 gb ram, da läufts am anfang eher mit 1gb/s, was den schnitt für kleine dateien hochtreibt
kurz bevor ich abgebrochen habe sah ich per nmon (32 sek zeitfenster) noch 110 mb/s auf den einzelnen platten mit einem einbruch auf 80 während ich mittels smartctl die platten abgefragt habe. Das entspricht dem erwarteten Wert für eine HDD dieser größe und ohne besonders hohe drehzahl.

Wie voll muss man also eine SMR Platte schreiben bis die Leistung einbricht? beim abbruch waren 78,5% belegt ohne dass viel passiert ist. Das passt schon eher nicht mehr zu der theorie dass der CMR Cache da etwas auffangen muss, denn wenn der so groß wäre bräuchte man SMR auch nicht mehr, oder?
 
Zuletzt bearbeitet: (korrektur)
  • Gefällt mir
Reaktionen: hRy, AlphaKaninchen und aklaa
@Bigeagle Diese synthetische Schreiblast ist vor allem... theoretisch. Es gibt nur sehr wenige Alltagssituationen, in denen man sequentiell mit Blockgrößen von 1 MiB schreibt bzw. liest. Interessanter sind die zufällig verteilten 4-KiB-Lesevorgänge. Dort sollten SMR-Platten tatsächlich genau so mies sein wie CMR-Platten. Zufällige, synchronisierte 4-KiB-Schreibvorgänge geben ihnen dann aber den Rest.

Beim SOHO-NAS, auf dem meine Film- und Musiksammlung liegt, könnte ich persönlich damit leben - einmal vollmachen und dann vergessen. In Produktivumgebungen (also auch kleinere Unternehmen) mit vielen kleinen Zugriffen sind SMR-Platten jedoch wertlos - die Schreibtechnik muss also unbedingt deklariert werden.
 
Frashman schrieb:
Na zumindest die tester wussten auch, dass das alles smr Platten sind.
Wieso alles? Im Fazit zur Barracuda steht das sie die einzige Platte im Test mit SMR ist.

Das Thema Cache verwirrt mich etwas. Meine beiden Platten (ST6000VN0033) haben auch 256 MB, aber im verlinkten Test steht im Fazit (Abschnitt NAS-HDD) das es PMR sind.

Nachtrag: Hab mir mal zu 3 Platten die Datenblätter angesehen: Seagate Barracuda 6TB ST6000DM003 mit SMR, die neuere Seagate IronWolf 6 TB ST6000VN001 der SMR nachgesagt wird und die ältere Seagate IronWolf 6TB ST6000VN0033 aus dem HWluxx-Test, die ich auch habe.

Alle 3 haben 256 MB Cache. Aber nur die Barracuda und die neuere IronWolf (VN001) haben eine Spurdichte (track density) von 540, während die ältere IronWolf (VN0033) 370 hat. Daraus schließe ich das Platten mit 256 MB nicht automatisch alle SMR nutzen. Ist aber auch echt verwirrend.
 
Zuletzt bearbeitet von einem Moderator:
.Silberfuchs. schrieb:
Wieso alles? Im Fazit zur Barracuda steht das sie die einzige Platte im Test mit SMR ist.

Stimmt - vorhin auf dem Handy falsch gelesen.

Nein dürfte ne CMR sein.
https://geizhals.de/seagate-ironwolf-nas-hdd-6tb-st6000vn0033-a1704647.html
Ergänzung ()

mgutt schrieb:
Wie gesagt nur eine Schlussfolgerung von mir, aber was sonst sollte TRIM auch machen um die Schindel mittendrin wieder verfügbar zu machen. Und das ständige Auslesen und neu beschreiben der Schindeln ist ja genau der Grund dafür warum SMR (gerade bei RAIDs) so lahm wird.

Zumindest sagt mein Linux nicht, dass die Platte überhaupt TRIM unterstützt.

Enabled Supported:
* SMART feature set
Security Mode feature set
  • Power Management feature set
  • Write cache
  • Look-ahead
  • Host Protected Area feature set
  • WRITE_BUFFER command
  • READ_BUFFER command
  • DOWNLOAD_MICROCODE
Power-Up In Standby feature set
* SET_FEATURES required to spinup after power up
SET_MAX security extension
  • 48-bit Address feature set
  • Device Configuration Overlay feature set
  • Mandatory FLUSH_CACHE
  • FLUSH_CACHE_EXT
  • SMART error logging
  • SMART self-test
  • General Purpose Logging feature set
  • WRITE_{DMA|MULTIPLE}_FUA_EXT
  • 64-bit World wide name
  • WRITE_UNCORRECTABLE_EXT command
  • {READ,WRITE}_DMA_EXT_GPL commands
  • Segmented DOWNLOAD_MICROCODE
  • unknown 119[6]
  • unknown 119[7]
  • Gen1 signaling speed (1.5Gb/s)
  • Gen2 signaling speed (3.0Gb/s)
  • Gen3 signaling speed (6.0Gb/s)
  • Native Command Queueing (NCQ)
  • Host-initiated interface power management
  • Phy event counters
  • READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
  • DMA Setup Auto-Activate optimization
  • Device-initiated interface power management
  • Software settings preservation
unknown 78[7]
  • SMART Command Transport (SCT) feature set
  • SCT Write Same (AC2)
  • SCT Data Tables (AC5)
unknown 206[7]
unknown 206[12] (vendor specific)
unknown 206[13] (vendor specific)
* DOWNLOAD MICROCODE DMA command
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Iapetos schrieb:
Diese synthetische Schreiblast ist vor allem... theoretisch. Es gibt nur sehr wenige Alltagssituationen, in denen man sequentiell mit Blockgrößen von 1 MiB schreibt bzw. liest. Interessanter sind die zufällig verteilten 4-KiB-Lesevorgänge.
Ich vermute langsam dass bei diesem irrtum der hund begraben liegt. Ich habe es zwar nicht probiert, aber ich vermute mal dass die SMR Platten tatsächlich schwach sind als 'hier schreibe ich jeden krümel der anfällt einzeln rein'-platten.

Also nein, paar GB mit Blocksize > 64k ist nicht nur theoretischer Natur, auch wenn ich hier mangels ausreichend schneller Datenquelle (welch ironie bei einer diskussion über langsame SMR platten XD) auf /dev/zero zurückgreife. /dev/urandom ist nicht schnell genug (!) auf einem Xeon E3 1231 v3 und die anderen einzelplatten sowieso nicht. SSD ist keine im Server drin und LAN hat auch nur Gbit.

Ich benutze meine dem namen entsprechend als archiv. Abgesehen davon dass 4k Zugriff auch praktisch nur bedingt relevant ist da selbst mein NTFS i.d.r. 16k blöcke nutzt hat das zfs bei mir die standardmäßige recordsize von 128k. Das ist näher an 1MiB dran als an 4kiB ;)
Dazu liegen dort eher größere Dateien, alles unter 2MB dürfte schon selten sein. Dann ist das von außen read-only. Praktisch hat nur root schreibzugriff, das verhindert auch gleich dass irgendwer oder irgendwas nur durch zugriff auf die freigabe meinen kram löschen kann. Nicht gerade sauber über root zu gehen, aber da privat, nur ein nutzer usw weniger wichtig.
Aufgrund dessen habe ich damals auch zu den Archive HDDs gegriffen, ich wusste dass mein geplanter Workload selbst im ungünstigen Fall gut auf SMR passt. Doch das läuft bisher eher performanter als ich erwartet hätte.

Sequentiell ist die Blockgröße übrigens längst nicht so wichtig für die Platte, das frisst ordnungsgemäß der Cache, wenn auch nicht völlig, womit das zur reinen schonung von CPU-zeit wird
root@deepspacewalrus:/mnt/archiv/test# dd if=/dev/zero of=testfile status=progress bs=4k count=256k
262144+0 Datensätze ein
262144+0 Datensätze aus
1073741824 Bytes (1,1 GB, 1,0 GiB) kopiert, 2,0721 s, 518 MB/s
root@deepspacewalrus:/mnt/archiv/test# dd if=/dev/zero of=testfile status=progress bs=4k count=1M
1048576+0 Datensätze ein
1048576+0 Datensätze aus
4294967296 Bytes (4,3 GB, 4,0 GiB) kopiert, 9,99878 s, 430 MB/s
root@deepspacewalrus:/mnt/archiv/test# dd if=/dev/zero of=testfile status=progress bs=4k count=10M
10485760+0 Datensätze ein
10485760+0 Datensätze aus
42949672960 Bytes (43 GB, 40 GiB) kopiert, 183,867 s, 234 MB/s
<BOINC pausiert>
root@deepspacewalrus:/mnt/archiv/test# dd if=/dev/zero of=testfile status=progress bs=4k count=10M
10485760+0 Datensätze ein
10485760+0 Datensätze aus
42949672960 Bytes (43 GB, 40 GiB) kopiert, 173,637 s, 247 MB/s
<CPU-Zeit Test>
root@deepspacewalrus:/mnt/archiv/test# rm testfile
rm: reguläre Datei 'testfile' entfernen? j
root@deepspacewalrus:/mnt/archiv/test# time dd if=/dev/zero of=testfile status=progress bs=4k count=1M
4073639936 Bytes (4,1 GB, 3,8 GiB) kopiert, 10 s, 407 MB/s
1048576+0 Datensätze ein
1048576+0 Datensätze aus
4294967296 Bytes (4,3 GB, 4,0 GiB) kopiert, 10,8925 s, 394 MB/s

real 0m10,894s
user 0m0,308s
sys 0m6,524s
root@deepspacewalrus:/mnt/archiv/test# rm testfile
rm: reguläre Datei 'testfile' entfernen? j
root@deepspacewalrus:/mnt/archiv/test# time dd if=/dev/zero of=testfile status=progress bs=1M count=4k
4213178368 Bytes (4,2 GB, 3,9 GiB) kopiert, 7,00199 s, 602 MB/s
4096+0 Datensätze ein
4096+0 Datensätze aus
4294967296 Bytes (4,3 GB, 4,0 GiB) kopiert, 7,32313 s, 586 MB/s

real 0m7,325s
user 0m0,012s
sys 0m1,008s

Wer natürlich eine SMR platte fürs system, spiele oder feingranulare häufig veränderte daten benutzt hat ein problem, sofern die keine wirklich guten kompensationsmechanismen haben. Aber sowas macht man ja auch nicht, das wäre hardwarequälerei.
Meine Spiele laufen auf den Ironwolf (ST8000VN0022) übrigens ziemlich gut. Von wegen HDDs und zu langsam. Nicht gerade SSD-ähnlich, aber bei den meisten Spielen sind die Ladezeiten nicht durch die Platte bedingt. Ausnahmen die mir einfallen wären Stars in Shadow, Silent Hunter 3 mit mods oder Path of Exile. Aber für sowas habe ich die 840 pro seit eine 850 evo als systemplatte arbeitet.
Letztlich ist es allgemein so dass man Dinge entsprechend seiner Eignung nutzen muss wenn man gute Ergebnisse haben will. Gilt für Computerhardware genauso wie für Bleistifte oder Kuchenmehl. Daher sollte das eigentlich auch nicht schwer zu verstehen sein.
 
  • Gefällt mir
Reaktionen: AlphaKaninchen
DerKonfigurator schrieb:
Und dabei kosten Festplatten gefühlt seit 10 Jahren das Gleiche. Also mit SMR nichtmals billiger...

Das ist so nicht richtig. Es gibt bei allen Herstellern nicht ohne Grund verschiedene Modelle mit eben unterschiedlichen Kosten. You get what you pay for.

Und es ist klar das damit sie günstiger als die anderen sind, etwas anders sein muss. Es wird für die Hersteller hier eine einfach Entscheidung gewesen sein bei den Einstig Lösungen die primär nur als "Backup aka Datengrab" gedacht sind, man die in der Herstellung günstigste Variante verbaut. Und dies bei den günstigeren Alsway on = 24/7 NAS Modellen (die aber natürlich wegen der robusteren Mechanik um die 24/7 Lauffähigkeit garantieren zu können teurer als die Desktop Varianten sein müssen) wo es von der Herstellung möglich ist ebenso verfährt. Daher ist deine Aussage es sei nicht mal billiger falsch es ist günstiger denn es gibt bei jedem Hersteller zig Modellreihen je nach Anwendungsbereich bzw. den Anspruch an diesen egal ob für Desktop oder NAS.

Ob die Festplatten nun allgemein zu teuer sind ist ein anderes Thema und gehört hier nicht hin.

Das die Hersteller dies aber allgemein in den Technischen Daten bei ALLEN Modellen angeben sollten, sollte eigentlich klar sein. Warum sie es nicht bzw. wie man bei Beispiel Seagate sieht nicht immer tun ist eine Frage die praktisch nur die Redaktionen weltweit @CB durch immer wieder Nachfragen klären können.
 
Zuletzt bearbeitet:
Gamefaq schrieb:
Warum sie es nicht bzw. wie man bei Beispiel Seagate sieht nicht immer tun ist eine Frage die praktisch nur die Redaktionen weltweit @CB durch immer wieder Nachfragen klären können.
Vermutlich traut man nur den Enterprise Anwendern zu sich nicht von SMR abschrecken zu lassen, weil man diesen zutraut die Auswirkungen auf den eigenen Anwendungsfall einschätzen zu können. Bei HGST wurde es noch vorbildlich in Großbuchstaben auf die Platte gedruckt:
Unbenannt.jpg
 
Nolag schrieb:
Vermutlich traut man nur den Enterprise Anwendern zu sich nicht von SMR abschrecken zu lassen, weil man diesen zutraut die Auswirkungen auf den eigenen Anwendungsfall einschätzen zu können. Bei HGST wurde es noch vorbildlich in Großbuchstaben auf die Platte gedruckt:
Anhang anzeigen 903536


Genau darum geht es ja. Man muss wissen was man tut bzw. in diesem konkreten Fall wofür man diese Platten benötigt. Wer sie wie gedacht (AUCH IM NAS!) als günstige Backup Lösung einsetzt wir nie wirkliche Probleme haben. Da aber viele Verkäufer den Kunden aber auch viele Privat die es eigentlich wissen sollten Raid als Backup bzw. höhere Datensicherheit verkaufen bzw. erklären , dadurch richten viele ein Raid ein das sie gar nicht benötigen.

Ich selbst nutze seit Jahren die hier oder in anderen aktuellen Festplatten Themen erwähnten WD RED 6TB , Seagate Archive 8 TB sowie Seagate EXO 10 TB mit einem NAS. Ebenso Freunde. KEINER hat Probleme. Denn KEINER nutzt RAID XYZ. Sie dienen als das was sie gedacht sind als Ablage für die eigene Film/Serien/Musik/Bilder Sammlungen. Dafür benötigt man kein Raid und Backups existieren auf EXTERNEN Festplatten.
 
@Gamefaq
Es geht doch nicht um deine 5 Jahre alten REDs. Die werden in 10 Jahren auch noch laufen. Sondern um den heimlichen Beschiss bzgl. Aufnahmeverfahren bei neuen Platten und den dadurch resultiernden Performanceverlust.
 
Zuletzt bearbeitet:
Nolag schrieb:
Bei HGST wurde es noch vorbildlich in Großbuchstaben auf die Platte gedruckt
Das sind/waren (WD hat das Label der Tochter HGST für HDDs Ende 2018 eingestellt) host managed SMR Platten, also solche mit denen nur Systeme etwas anfangen können die mit host managed SMR Platten kompatibel sind. Die anderen SMR HDDs wie die Red um die es in der News geht, sind device managed, da merkt man außer an der Performance nicht, dass es SMR Platten sind. Bei Seagate sind (oder waren zumindest die ersten Archive) die device managed SMR Platten auch host aware, da konnte der Host also sie also optional auch wie host managed SMR Platten behandeln, also erfahren welche Spuren überlappend sind.
 
  • Gefällt mir
Reaktionen: sysrq
Iapetos schrieb:
Dazu gibt es gerade frisch einen sehr ausführlichen Artikel bei Ars Technica.

Verstehe nicht was du meinst im Artikel geht es um mdraid (Software) vs Hardware Raid, ZFS ist zwar auch "Software" basiert, aber zu "normalen" software Raid Lösungen gibt es erhebliche Unterschiede (mdraid, intel matrix raid, etc.).

Probleme mit RAID5 sind heutzutage praktisch vorprogrammiert, wüsste nicht wie eine Hardware Lösung dem entgegenwirken könnte.

RAID10 oder ZFS striped mirror!
 
Zuletzt bearbeitet:
.Silberfuchs. schrieb:
Also ich habe letztes Jahr zu den ST6000VN0033 für meine Synology gegriffen und die scheinen kein SMR zu haben. HWluxx hatte verschiedene Platten im Test und ist auch auf SMR eingegangen wie bei der Barracuda. Bei den ST6000VN0033 war davon nix zu lesen, sonst hätten sie sicher nochmal extra darauf hingewiesen.

Hallo zusammen!

Und auch die Seagate Exos haben nicht grundsätzlich SMR.
Meine Seagate Exos 7E8 (ST8000NM0055), bzw. grundsätzlich Seagate Exos 7E8 werden als CMR ausgewiesen.

Aus https://www.seagate.com/files/www-c...e8-msft-data-sheet-DS1957-4M-1909DE-de_DE.pdf
Festplatte der Enterprise-Klasse für datenintensive
Anwendungen
Exos 7E8-Festplatten bieten bis zu 8 TB Speicherkapazität pro Festplatte
1 und eignen sich
perfekt für den Einsatz als Massenspeicher für Rechenzentrumsinfrastrukturen, bei denen
extrem zuverlässige Festplatten der Enterprise-Klasse vonnöten sind. Die Exos 7E8 ermöglicht
den kosteneffektiven, zuverlässigen Zugriff auf unstrukturierte Daten. Die Exos 7E8-Festplatte
basiert auf der bewährten CMR-Technologie (klassische Magnetaufzeichnung) der 10.
Generation und hilft bei der Katalysierung der Datensphäre. Damit profitieren
Rechenzentrumsarchitekten und IT-Experten von bewährter Leistung, höchster Zuverlässigkeit
und Sicherheit und geringen Gesamtbetriebskosten für anspruchsvolle Umgebungen bei
Dauerbetrieb.
Robuster Speicher für große Datenmengen für den
Dauerbetrieb
Exos 7E8-Festplatten bieten einen MTBF-Wert von 2 Millionen Stunden und unterstützen
Workloads von bis zu 550 TB pro Jahr – die zehnfache Leistung von Desktop-Festplatten. Mit
hochmodernem Cache und Algorithmen für die Ad-hoc-Fehlerkorrektur sowie
Rotationsschwingungsdesign gewährleistet die Exos 7E8 konstante Leistung in replizierten
Systemen und RAID-Systemen mit mehreren Festplatten.

Wie auch die Auskunft bei Geizhals. https://geizhals.de/seagate-exos-e-7e8-8tb-st8000nm0055-a1325917.html#offerlist



Seagate Exos E 7E8 8TB, 512e, SATA 6Gb/s (ST8000NM0055)

Formfaktor​
3.5"
Drehzahl​
7200rpm
Cache​
256MB
Leistungsaufnahme​
10W (Betrieb), 9W (Leerlauf)
Lautstärke​
keine Angabe (Betrieb), keine Angabe (Leerlauf)
Aufnahmeverfahren​
Conventional Magnetic Recording (CMR)
Sektoren​
4KB mit Emulation (512e)
Zuverlässigkeitsprognose​
2 Mio. Stunden (MTBF)
Datenschutzfunktionen​
N/A
Besonderheiten​
geeignet für Dauerbetrieb, Feuchtigkeitssensor
Herstellergarantie​
fünf Jahre
Hinweis​
Nicht gekennzeichnete OEM/System Builder-Festplatten im Umlauf. Verminderte Garantieleistung möglich. Herstellergarantie über die Seriennummer überprüfbar.
Wichtig​
Zur Verwendung innerhalb eines RAID-Verbunds, sollten keine Festplatten mit unterschiedlichen Aufzeichnungsverfahren (CMR, SMR) kombiniert werden. Bei Verwendung von Festplatten mit SMR in einem RAID-Verbund, ist darauf zu achten, dass der RAID-Controller (bzw. das NAS-System) zu SMR-Festplatten kompatibel ist, um das teilweise geblockte Aufzeichnungsverhalten beim SMR nicht fälschlich als "Hardware-Defekt" zu deuten.
Gelistet seit​
17.09.2015, 11:24

Gruß Andi
 
  • Gefällt mir
Reaktionen: .Silberfuchs.
haze4real schrieb:
Verstehe nicht was du meinst im Artikel geht es um mdraid (Software) vs Hardware Raid, ZFS ist zwar auch "Software" basiert, aber zu "normalen" software Raid Lösungen gibt es erhebliche Unterschiede (mdraid, intel matrix raid, etc.).

Probleme mit RAID5 sind heutzutage praktisch vorprogrammiert, wüsste nicht wie eine Hardware Lösung dem entgegenwirken könnte.

RAID10 oder ZFS striped mirror!
Du verstehst nicht, was ich meine, weil du dich angegriffen fühlst. Ich wollte mit meinem Beitrag einfach deinen Beitrag unterstützen. 😉

Außerdem geht es in dem Artikel nicht primär um Software- gegen Hardware-RAID (nur in einem kleinen Abschnitt), sondern eben genau darum, dass RAID5/6 nur noch ganz selten sinnvolle Anwendungen sind und RAID10 erheblich sinnvoller ist.
 
  • Gefällt mir
Reaktionen: haze4real
Gamefaq schrieb:
Genau darum geht es ja. Man muss wissen was man tut bzw. in diesem konkreten Fall wofür man diese Platten benötigt. Wer sie wie gedacht (AUCH IM NAS!) als günstige Backup Lösung einsetzt wir nie wirkliche Probleme haben. Da aber viele Verkäufer den Kunden aber auch viele Privat die es eigentlich wissen sollten Raid als Backup bzw. höhere Datensicherheit verkaufen bzw. erklären , dadurch richten viele ein Raid ein das sie gar nicht benötigen.
Sry aber soviel Unfug auf einmal stört einfach nur in dem Thema. Backup ist Backup und RAID ist RAID. Die haben nichts miteinander zu tun.
Und nur weil hier RAID dazu geführt hat, dass man den Beschiss gemerkt hat, ist das kein Problem dieser Platten mit RAID, den zwei gleiche SMR Platten werden auch weiterhin im RAID funktionieren. Es ist eine Frechheit, wenn die Hersteller die langsameren SMR Platten ohne Kennzeichnung mit dem Namen verkaufen, der bis dato immer für normale Platten stand.
 
Zurück
Oben