Hdd-fabrikanten verzwegen gebruik shingled magnetic recording bij sommige disks

Toshiba, Seagate en Western Digital hebben toegegeven dat sommige van hun harde schijven shingled magnetic recording gebruiken, zonder dat dit gespecificeerd was. Deze techniek vergroot de opslagdichtheid, maar kan de i/o-prestaties nadelig beïnvloeden.

De website Blocks & Files berichtte eerder deze week over het gebruik van smr door Western Digital zonder dit te benoemen, en daarna over Seagate en Toshiba die hetzelfde deden bij bepaalde hdd-modellen. De bedrijven hebben toegegeven smr te gebruiken bij sommige harde schijven zonder dit bij de specificaties te zetten. Bij WD gaat het om Red-drives voor nas-systemen van 2TB tot en met 6TB. Bij WD Red 8TB tot en met 14TB drives gebruikt het bedrijf cmr, oftewel conventional magnetic recording.

Bij Seagate gaat het om onder andere Barracuda-schijven van 2TB, 4TB en 8TB en om Archive v2-hdd's van 6TB en 8TB. Bij Toshiba betreft het P300-desktopschijven van 4TB en 6TB en de DT02-modellen, waar de P300-versies op gebaseerd zijn. Ook de MQ04-hdd's voor laptops gebruiken smr, evenals de daar op gebaseerde L200-serie van Toshiba.

Blocks & Files werd getipt over het gebruik van smr door WD's voor de betreffende Red-modellen door onderzoekers die problemen ondervonden bij het toevoegen van zo'n drive aan bestaande raid-array's. De oorzaak lag bij de gebrekkige i/o-prestaties bij willekeurig schrijven. Bij shingled magnetic recording overlappen datatracks voor schrijven elkaar zodat meer data op de platters weggeschreven kan worden. Dit levert nadelen met betrekking tot de schrijfsnelheid op, wat deels op te lossen is door de cache te vergroten. Voor toepassingen met veel random write-acties, zoals bij nas-systemen het geval kan zijn, blijken de smr-schijven minder geschikt.

Reacties (147)

De meeste van dit soort schijven hebben een gedeelte dat als CMR beschreven wordt als een soort extra cache. In het Seagate MTC filmpje wat eerder is gelinkt hebben ze het over max 100GB. Dit wordt later sequentieel naar het SMR gedeelte gekopieerd op het moment dat een schijf idle is. Het is heel erg vergelijkbaar met QLC SSD's met een SLC gedeelte. Samen met het cache geheugen en andere firmware optimalisaties merk je bij licht gebruik weinig van SMR. Hoe voller de schijf is hoe meer moeite het kost om alle bitjes kwijt te kunnen op het SMR gedeelte.

Worst case scenario is een schijf die bijna vol zit waar je langere tijd achter elkaar random data gaat herschrijven. Dan kan een schijf zelfs "bevriezen" of tot bijna 0 vertragen totdat alle SMR herschrijfacties zijn uitgevoerd en dat kan voor een RAID kaart of NAS reden zijn om de schijf uit de array te gooien. Je zou verwachten dat WD hier voor de REDs een oplossing voor heeft bedacht omdat die juist voor een NAS zijn bedoeld.

SMR is een prima techniek om meer data kwijt te kunnen, maar past gewoon niet bij alle workloads. Daarom is het jammer dat de fabrikanten niet duidelijker zijn zodat je een geïnformeerde keuze kan maken.

Ik gebruik zelf een aantal Seagate ST5000LM000 2,5inch 5TB schijven met SnapRAID waar ik alleen sequentieel grote mediabestanden op schrijf en vrijwel nooit herschrijf. Ik wist van te voren dat het SMR schijven waren maar met deze workload gaat het prima.

Sterker nog, de archive schijven van Seagate presteren dankzij meerdere cache technieke véle malen beter op writes, ook op 4K writes. Je moet dan denken aan 10 tot 12 MB/s bij 4K en 4K32 snelheden, daar waar een normale harde schijf blijft hangen op respectievelijk 0.5 MB/s en <2 MB/s.

Verder heb ik ook gemerkt dat een netwerk bottleneck in je voordeel werkt. Mijn archive schijven pieken op ongeveer 165 MB/s. Via het netwerk wordt dit begrensd op 120-125 MB/s hierdoor stort de performance niet in en kun je eigenlijk 8 uur lang met die snelheid data naar zo'n schijf pompen. Heb je die beperking niet dan gaat het in het begin ietsje harder maar daarna krijg je perioden van 1-10 MB/s schrijfsnelheden, iets dat eigenlijk alleen is op te lossen door de transfer enkele minuten te pauzeren. Een schijf kan immers niet goed meerdere dingen tegelijk

Voor de mensen die resilveren schijnt sequential resilvering 'de oplossing' te zijn overigens.

Voor de mensen die resilveren schijnt sequential resilvering 'de oplossing' te zijn overigens.

Doet dat iets anders dan wat het zegt en is daarmee de abysmale resilvering snelheid op bijna-vol vdevs verholpen ?

Het zou best wel kunnen dat het vergelijkbaar is met een SSD. Maar een HDD trekt zich veel meer aan van random IO. Dus het lijkt me dat een HDD hier wel veel meer moeite mee heeft als bijvoorbeeld mijn 660p systeem schijf. De vertraging is misschien evenveel percentueel, maar in gebruik wordt een HDD bijna onbruikbaar, en de SSD lijkt het grotendeels gewoon te doen.

Inderdaad, als je veel kleine blokken moet schrijven, dan moet je geen SMR drives hebben. Sterker nog, dan moet je uberhaupt geen HDD’s nemen.

Voor standaard media storage zijn SMR drives ideaal, voor bijvoorbeeld een intensief gebruikte database niet.

Ik vind het heel jammer dat dit niet een eigenschap is waar je op kunt filteren in de pricewatch. Ik moet nu zelf gaan onderzoeken of de schijven die ik op het oog heb SMR of PMR zijn.

De langzamere SMR-Modelle zijn met EFAX (256 MByte Cache) gekenmerkt, de snellere PMR-Drives met EFRX (64 MByte cache). http://products.wdc.com/l...Sheet/ENG/2879-800002.pdf

Heel jammer dat ik dit een maand geleden niet wist en dus de verkeerde keuze gemaakt heb. Het verklaart wel waarom je voor ongeveer dezelfde prijs 4x zoveel cache mem. krijgt.
Wat is dan het voordeel voor de fabrikant, Eén lees/schrijf-kop minder?

Productiekosten, een platter minder waarschijnlijk.

Ik zou a.d.v. dit artikel gewoon een klacht neerleggen bij ze en een andere schijf eisen.
Je hebt voor bepaalde specificaties betaald en die heb je niet gekregen, dus lijkt me dat ze daar op zijn minst coulant mee om zouden moeten gaan.
niet geschoten, altijd mis...

Schijven kopen die op bedrijfsleven gericht zijn.

WD - Ultrastar serie staat nadrukkelijk bij of SMR/PMR zijn. Waarbij opvallend genoeg SMR ook echt wordt afgeraden voor random gebruik. SMR noemen ze daar "Highest Capacity. Sequential Write Workloads" schijven.

Hangt ervan af welk soort bedrijfsleven - voor servers met veel reads maar weinig writes is SMR prima.

Dat is een kwestie van met je portemonnee stemmen en dus geen Toshiba, Seagate en Western Digital meer kopen. Tenzij ze het roer omgooien (met daden), kan er niet meer op die merken vertrouwd worden. ER blijven genoeg alternatieven over, dus zo lastig is dat niet.

Ikzelf koop ook geen Logitech toetsenbord meer, omdat shops het telkens voor elkaar hadden gekregen om ANSI-layout (smalle Enter) met ISO-layout (Dikke Enter, |\ tussen kleine Linker Shift en z) te verwisselen waardoor ik bij 3 webshops de toetsenbord met ongewenste layout (ISO-layout) mocht terugsturen. Nooit meer.

[Reactie gewijzigd door RoestVrijStaal op 18 april 2020 01:13]

Umm, dat zijn de enige 3 HDD fabrikanten vziw.
Dan zou je op SSD moeten overstappen.

Toshiba, Seagate en WD zijn de enige drie overgebleven hdd-producenten. Tenzij je op SSDs omstapt (gezien de stagnerende SSD-prijzen zal het omstappen ook wel stagneren) is dat dus behoorlijk lastig.

Dat Logitech-probleem, lag dat aan Logitech of aan de webshops? Als er een SKU voor ANSI en een SKU voor ISO is zouden het de webshops schuld zijn, niet Logitech.

[Reactie gewijzigd door _Pussycat_ op 18 april 2020 05:40]

Welke alternatieven dan? Vziw ik weet gaat het hier namelijk prescies om de drie grote HDD boeren die als enige nog schijven produceren.

Ssd’s is leuk, maar voor meer capaciteit dan 2TB wil je pricewise toch echt gewoon HDD’s. anders is het niet te doen. Nu weten we gelukkig ook dat we dan dus ook echt de grote schijven moeten kopen en niet de 4tb modelletjes.

Het is inderdaad vervelend dat deze fabrikanten verzaken dit bij hun HDD's erbij te vermelden, helemaal als dit de performance/betrouwbaarheid blijkt te beïnvloeden.

De bedrijven hebben toegegeven smr te gebruiken bij sommige harde schijven zonder dit bij de specificaties te zetten. Bij WD gaat het om Red-drives voor nas-systemen van 2TB tot en met 6TB.

Voor toepassingen met veel random write-acties, zoals bij nas-systemen het geval kan zijn, blijken de smr-schijven minder geschikt.

Als NAS-gebruiker van 3x 3TB en 3x 4TB WD RED schijven wordt ik hier niet vrolijk van... Volgende lichting eens naar alternatieven kijken.

[Reactie gewijzigd door Silentpuma op 18 april 2020 13:21]

Elders las ik juist dat men bij WD vindt dat een NAS korte sequentiële bursts aan data uitvoert. Het verklaart in ieder geval wel e.e.a. voor mij (2x 6 TB Red mirror in NAS, 1x 8 TB Red offsite).

Volgens mij is er bij een NAS helemaal geen sprake van veel read and write-acties. De meeste thuis-NAS boxen bevatten video en foto's die 1x worden opgeslagen en dan een paar keer gelezen (voor indexeren en uiteraard bekijken).

In de tekst staat: "Voor toepassingen met veel random write-acties, zoals bij nas-systemen het geval kan zijn (...)"

Er zullen inderdaad wel enkele NAS systemen zijn die veel worden gebruikt. Die NAS'sen worden dan ook waarschijnlijk uitgerust met enterprise class harde schijven, omdat tijdelijke uitval veel duurder is dan een paar tientjes meer per harde schijf.

Wat dacht je van bijvoorbeeld synology cloud of backup vanaf verschillende systemen naar je NAS? Dat kan natuurlijk behoorlijk in de weg gaan zitten als die systemen allemaal om 2 uur 's nachts gaan syncen.

Wat ik me echter ook afvraag is of die overlappende tracks ook voor een grotere uitval van de schijven kan zorgen.
Bijvoorbeeld extra errors door integriteitsissues, maar ook tgv dynamische problemen omdat de read/write head wellicht meer bijgestuurd moet worden, wat dan weer hogere slijtage tot gevolg kan hebben. Iemand die hier een licht op kan werpen?

Als alle systemen om twee uur ‘s nachts gaan syncen heb je ook wel een relatief slecht systeem moet ik zeggen. Dat is namelijk vragen om problemen. Met iets als Timemachine worden er realtime snapshots gemaakt en gesynced. Dit zorgt ervoor dat load veel meer verspreid wordt over de dag. En dat het steeds eigenlijk maar kleine dingen zijn. Hierdoor heb je eigenlijk altijd een up to date back up en kun je in geval van failure echt direct weer verder zonder gegevens verlies.

Ik maak Time-Machine backups naar mijn Synology die hier op locatie staat en elke nacht maakt deze Nas een sync met een andere Synology Nas die buiten de deur staat. Dus zo 'slecht' hoeft het niet te zijn.

Maar die sync is dan weer geen random IO van meerdere sources maar gewoon sequentieel. Dan is het een heel ander verhaal dan dat je vanaf 3 of meer sources tegelijk een snapshot gaat draaien naar dezelfde source.

snap ik niet?
Nou heb ik geen NAS (vind 't te duur nog), maar als ik een NAS had, zou het juist NIET zijn voor de video's die 1 x opgeslagen worden, maar juist om alle pc's hier in huis te synchroniseren.
Dus juist om alle data die steeds wijzigt en die nu her en der staat, op 1 plek te waarborgen en vanaf die plek de pc's weer te voeden.
Gaat om honderden juist kleinere bestanden (saved games, word documenten, excel documenten, foto's, eigengemaakte filmpjes, etc etc) dus lijkt mij juist wel veel kleinere read en write acties.

Ik kan je vertellen, ik heb een NAS met 5 RED schijven waarbij ik afgelopen 4 jaar 2x uitval heb gehad. Helaas was de 2e uitval net na de garantie van 3 jaar. Voorheen gebruikte ik goedkope Green disks van Samsung die niet voor NAS bedoeld waren (wel ondersteund door de NAS), en serieus nooit problemen gehad. Die had ik geupgrade van 5x 500 naar 5x 1TB en later 5x 2TB. Nu bij 4TB ging ik voor "pro", echte NAS schijven erin dus. Pffff, bestonden die Samsung schijven nog maar, en had ik nu goedkoper en beter bij gezeten.

Je moet de 8TB hebben

In dit verhaal is het niet duidelijk of die I/O prestaties zoals gespecificeerd zijn. Ik vermoed dat deze fabrikanten nog wel meer technieken gebruiken die ze niet specifiek benoemen.

Het gaat er bij WD ook om dat ze deze aanpassing stiekem doen. Iedereen is tevreden van de WD Red reeks, ze hebben een goede reputatie, goede reviews, mensen die er wat bijkopen op basis van goede ervaringen "zo wil ik er nog wel een want die werkt goed". Nu blijkt dat ze stilletjes gewisseld zijn naar een tragere techniek, voor dezelfde prijs. Zo'n techniek hoef je niet specifiek te benoemen als je bijvoorbeeld disks voor archival maakt, maar als je zegt dat ze voor NAS gebruik zijn mag je toch wel goede schrijfprestaties verwachten in plaats van een techniek die getypeerd wordt door slechte random writes. In het begin werd zelfs actief ontkend dat ze SMR gebruikten, nadat dit onder andere via de Synology compatibiliteitslijsten was uitgelekt.

Doorgaans zijn de IO prestaties identiek of beter (dankzij de grotere cache).

Hebbelijkheid is dat ze af en toe "idle" tijd nodig hebben om hun eigen administratie te doen, net als SSDs met gemixte SLC en MLC opslag.

Als de schijf regelmatig idle is, dan is er niks aan de hand.

Als hij volcontinue gebruikt wordt, dus continue schrijven en lezen zonder enige onderbreking, dan moet de disk controller op den duur alles even "on hold" zetten om zijn taken te kunnen doen om de data veilig te stellen. Op dat moment stort de performance helemaal in en komt er even niks meer in of uit.

In een NAS zal je gigabit ethernet verbinding een voldoende grote bottleneck vormen om de disk zijn achtergrond taken zonder problemen te laten uitvoeren.

[Reactie gewijzigd door cdwave op 18 april 2020 20:04]

wat gebeurt er als je je comp uitzet net als die disk controller ff zijn taken aan het afmaken is?

Dan gaat hij daarmee verder kort nadat de prik er weer op gaat.

WD doet geen uitspraken over random-write taken van hun schijven, terwijl die writes juist het meest door deze SMR worden geraakt.

En welke prestaties specifieert WD dan? Als ik de specsheet bekijk voor mijn 3TB Reds staat er niet meer dan: Interface Transfer Rate up to 180MB/s. Dat is een maximum. Zegt niets over 'n minimum. HDD fabrikanten zijn bijzonder karig met informatie over wat ze nou precies verkopen. Uiteindelijk moet je dus naar de kleurtjes / marketing kijken. Red voor NAS. Dat schept verwachtingen. SMR is iets wat je niet verwacht, omdat het over-time nadelige performance specs heeft.

The smartmontools ticket thread includes a March 30, 2020, mail from Yemi Elegunde, Western Digital UK enterprise and channel sales manager:

“Just a quick note. The only SMR drive that Western Digital will have in production is our 20TB hard enterprise hard drives and even these will not be rolled out into the channel. All of our current range of hard drives are based on CMR Conventional Magnetic Recording. [Blocks & Files emboldening.] With SMR Western Digital would make it very clear as that format of hard drive requires a lot of technological tweaks in customer systems.”

Nu is dit niet wat er op hun datasheet staat... Maar wel een ontzettende naai streek.

Er is trouwens niks mis met SMR drives.. Ze hebben gewoon een andere inzet en de prijs moet lager zijn.
Maar hier zo glashard over liegen is een drama.

Verklaart ook gelijk dat ze niet lager geprijsd zijn.

Dit zou verklaren waarom de hogere capaciteit schijven vaak iets sneller gespecificeerd staan.
Viel me ooit op tijdens het "pricewatchen".

Zijn I/O prestaties *ooit* zoals gespecificeerd?

Zijn SMR schijven ook minder betrouwbaar? of alleen langzamer?

Hangt van de toepassing of. Ik gebruik FreeNAS met ZFS. De performance wordt op den duur slechter. Stel dat je 'n pool hebt met deze SMR drives en er valt er één uit. Je pool is dan degraded en je vervangt de defecte schijf. Nu moeten die andere SMR drives, die ook al 'n tijd mee gaan, de resilver verzorgen voor die nieuwe schijf. Best case duurt dan héél lang (ik heb verhalen gehoord van 'n resilver die normaal 1 dag duurt, nu 5 dagen duurt). Worst cast performt de rest van die SMRs dusdanig slecht dat ze read errors / timeouts gaan geven. Je resilver gaat dan nooit gebeuren en je pool is niet meer te herstellen. Afhankelijk van je situatie en up-time verplichtingen ben je dan met die WD Red schijven mooi de sjaak, zeker omdat deze schrijven als 'NAS' schijven verkocht zijn.

Ik heb hier een ZFS mirror van twee 5TB SMR schijven via USB3 aangesloten. Deze is voor 90% vol (4.10T / 4.55T). Een scrub duurt 13 uur. Dat vind ik meer dan redelijk. Ook goed om te realiseren:

Scrub and resilver use exactly the same code

Uit de video hieronder gelinkt.

Daarbij is het probleem wat je beschrijft inderdaad lang van toepassing geweest binnen ZFS. Echter met de sequential scrub and resilver een stuk minder een probleem. Je zal in recente ZFS versies ook zien dat de output van de scrub anders is dan je gewend was.

root@pve:/# zpool status rpool
pool: rpool
state: ONLINE
scan: scrub in progress since Fri Apr 17 20:23:18 2020
4.93G scanned at 505M/s, 2.70G issued at 276M/s, 4.93G total
0B repaired, 54.68% done, 0 days 00:00:08 to go

Het verschil is de nu scanned en issued splitsing die er in oudere versies niet was.
Dit is overigens een ZFS mirror van SSD's. De oude output was dit (willekeurig van internet):

# zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Sat Dec 8 08:06:36 2012
32.0M scanned out of 48.5M at 16.0M/s, 0h0m to go
0 repaired, 65.99% done

Uitleg van de commit in ZoL

Currently, scrubs and resilvers can take an extremely long time to complete. This is largely due to the fact that zfs scans process pools in logical order, as determined by each block's bookmark. This makes sense from a simplicity perspective, but blocks in zfs are often scattered randomly across disks, particularly due to zfs's copy-on-write mechanisms.

This patch improves performance by splitting scrubs and resilvers into a metadata scanning phase and an IO issuing phase. The metadata scan reads through the structure of the pool and gathers an in-memory queue of I/Os, sorted by size and offset on disk. The issuing phase will then issue the scrub I/Os as sequentially as possible, greatly improving performance.

This patch also updates and cleans up some of the scan code which has not been updated in several years.

https://github.com/openzf...df6d0ae33196f5b5decbc48fd
https://github.com/openzfs/zfs/pull/6256

How Has This Been Tested?

Initial performance tests show scrubs taking 5-6x less time with this patch on a 47TB pool consisting of data mimicking our production environment. On zfs version 0.6.8, the scrub took a little over 125 hours while it only took 22.5 with this patch. @skiselkov 's presentation at the developer summit cited a 16x performance improvement for a worst case scenario.

As this patch solidifies we will add more formalized automated tests.

PDF van de oorspronkelijke PoC van dit idee:
https://drive.google.com/...e4cdmVU91cml1N0pKYTQ/view
met een presentatie:
https://www.youtube.com/w...wv8BdBj4&feature=youtu.be

Presentatie van de OpenZFS Developer Summit:
https://www.youtube.com/watch?v=upn9tYh917s

Het zit dus al in ZoL 0.8 and FreeNAS 11.1
https://www.ixsystems.com...ntial-scrub-and-resilver/

Mijn ervaringen worden gedeeld door andere gebruikers:

Both the scrub and resilver performace is MANY times faster with the new sequential scrub/resilver code. On my 6TB WD ES drives, it starts off slow at ~80-100 MB/s, then after about 15 minutes or so ramps up unto the hundreds of MB/s and stays there until it's done. Its also much quieter. Scrubs and resilvers used to thrash drives terribly, and now they thrash for the first minute or so then go almost silent unless you try to access the array during the resilver process.

https://arstechnica.com/c....php?p=37591199#p37591199

[Reactie gewijzigd door CurlyMo op 17 april 2020 22:05]

Wat heeft dit met SMR specifiek te maken?

Bij een rebuild heeft de schijf vrijwel geen 'idle time'.
SMR schijven gebruiken een deel van de schijf wat niet SMR is voor de random write operaties.
In de 'idle time' gaan ze dan dat stukje in alle rust overzetten naar een SMR deel.
Dit omdat je voor SMR een heel blok van meerdere tracks in 1x moet schrijven.

Van een block van zeg 3 tracks kun je niet iets in track 1 schrijven zonder track 2 en 3 te overschrijven.
Daarna moet je dus track 2 schrijven en daarna track 3.
Oftwel 1 bit aanpassen in een block kan betekenen dat je het hele block opnieuw moet inlezen, in het geheugen bijwerken en weer wegschrijven.

Omdat de performance hiervan dramatisch is, gebruiken ze dus een stukje wat niet 'shingled' is, maar dat is maar beperkt in grootte (en neemt af als de schijf verder volgeschreven is).

Bij een rebuild van ZFS, RAID of een andere methode als bijvoorbeeld erasure code, heb je dus niet die benodigde idle time.
De rebuild zou goed kunnen gaan, als alles sequentieel zou gaan, maar zoals door anderen opgemerkt gaat het vaak om een systeem wat "online" is en dus af en toe ook schrijft.
Naarmate je dus verder in de rebuild komt, krijg je steeds meer te maken met de benodigde 'idle time' en dat kan zo ver oplopen dat je volume manager constateert dat de schijf offline is en de sync afbreekt.

Precies dit idd.

Als je een 8-disk raid setup bouwt (voor redundancy) dan ben je juist gebaat bij geen gezeik tijdens resilvers/rebuilds. Het is al je adem inhouden tijdens rebuilds want vaak draaien de overige drives ook al een aanzienlijke tijd en hebben die qua levensduur bovendien een soortgelijke verwachting als de schijf welke je op dat moment vervangt ("borrowed time").

Ik stond - als hdd leek - juist op het punt om 8 van die 6-TB RED drives aan te schaffen, want de niet-budget lijn van WD leek me gezien veel positieve reviesw een goede optie voor gebruik in raid setups. Hij is er in 256MB cache uitvoering ipv in 64MB cache -> no-brainer, right? Pff.

Ik weiger pertinent om meer dan 1500 euro aan schijven te bestellen die onbetrouwbaar presteren tijdens rebuilds; een van redenen dat ik dat geld aan storage-schijven wil uitgeven is juist om dit doort ellende te voorkomen. Erg fijn (voor mij) dat het eea wat breder in de storage-community wordt uitgemeten momenteel. Las ook dat sommige tweakers juist van dit soort schijven hadden aangeschaft, das flink balen.

Ik vond deze blacklist:

https://www.ixsystems.com...-of-known-smr-drives.141/

trouwens wel nuttig. De FreeNAS community heeft in mijn boekje een goed track-record qua up2date houden van dit soort lijsten.

Ik ga niet op specifieke EFRX EZRZ strings filteren bij aanschaf van een HDD. Wat doe je als een webshop je toch onverhoopt een andere versie toestuurt bv?

Geen WD RED voor mij, te verwarrend/complex.

Het gaat toch vooral om random write acties die langzaam zijn bij een rebuild is hier toch geen spraken van ? Of is het uitlezen van dit soort schijven ook slechter ? Dat kan ik in het artikel niet terug vinden.

Een rebuild van een raid 5 bijvoorbeeld is toch ook een hele scheepslading van random schrijfacties van alle overige schijven uit je NAS naar de nieuwe schijf?

Een rebuild van een raid 5 bijvoorbeeld is toch ook een hele scheepslading van random schrijfacties van alle overige schijven uit je NAS naar de nieuwe schijf?

Dat is eerder sequential dan random, lijkt me? Je rebuild niet een stukje van een disk, maar de hele disk van begin tot eind?

Dat is eerder sequential dan random, lijkt me? Je rebuild niet een stukje van een disk, maar de hele disk van begin tot eind?

Data staat niet volledig sequentieel weggeschreven, dus het zijn in elk geval random reads. En als read/write gaat interleaven en de arm moet bewegen is dat netto hetzelfde effect als random writes.

Zover ik weet van mijn eigen ervaring is dat het rebuilden toch sequenteel gaat. Enige waar je last van hebt als je online aan het rebuilden bent dat de reguliere lees en schrijf acties dus tussendoor komen, dat veroorzaakt dat de array erg traag is en ook traag rebuild.

Nee dat gebeurt in principe sequentieel. Maar een raid array is ook gewoon online tijdens een rebuild. Voor de nog intacte schijven is een rebuild in principe sequentieel lezen, en voor de nieuwe schijf sequentieel schrijven. Als je tijdens de rebuild nieuwe data naar het array gaat schrijven krijgt met name de disk die aan het rebuilden is wel wat meer random schrijfacties.

RAID op diskniveau is heel sequentieel qua rebuild. Van alle schijven wordt block X gelezen, die worden gecombineerd en dat wordt block X van de te herstellen schijf.
Parity die in het file system wordt gemanaged werkt meestal anders: een fil eis dan bijvoorbeeld gemirrord over 2 disks. Als 1 van die 2 weg is, gaat het systeem die tweede helft ergens anders opzetten (in de free space) en dat is random access.

Bij normaal RAID niet - die staat te rebuilden zonder dat er andere activiteit is. ZFS is gewoon in-operation terwijl de resilver uitgevoerd wordt. Dus je hebt ook nog random writes naast dat je de resilver doet.

Ik heb werkelijk nog nooit een RAID systeem gezien wat niet gewoon operationeel een resync uitvoerd (in ieder geval in de afgelopen 20 jaar).

in ieder geval in de afgelopen 20 jaar

Look, some of us are old... OK! ;-)

Serieus, ik heb ook meegemaakt dat oude RAID sets alleen konden rebuilden als ze inaccesible waren. Dat doen mijn Synology NASen al heel lang niet, maar het is niet onbekend.

Ooit een antiek HP ding... die hoefde niet inaccessible, maar als er een access was stopte hij met de rebuild. Ik denk wel een minuut of zo. Geen succes, dan kan je net zo goed niet rebuilden.

Dit is onzin, een RAID set kan en zal ook gewoon operationeel zijn wanneer deze een rebuild uitvoert, zonder enig probleem. Dat is dan ook waar je een RAID systeem voor gebruikt, om de uitval van één of meerdere harde schijven op te kunnen vangen (afhankelijk van RAID level) terwijl de data gewoon beschikbaar blijft 24/7.

Daarnaast in het artikel wordt aangegeven dat het ontdekt werd bij bij plaatsen van harde schijven, ik vraag mij af is er wel voldaan aan de specificities opgegeven door de fabrikant. Bijvoorbeeld maximal zoveel harde schijven in één RAID set van een bepaald type harde schijf.

De RED-harde schijven van WD doen gewoon waar zij voor gemaakt zijn, maar je moet je wel aan de specificities houden, als je out-of-sec gaat werken, dan kan een fabrikant ook niets garanderen.

Ik vind het artikel net iets te weinig achtergrond informatie hebben om hier een goed oordeel over te kunnen gegeven.

[Reactie gewijzigd door _Dune_ op 17 april 2020 18:58]

Op Linux met mdadm, of een Areca kaartje (hardware RAID) kunnen dit echt al vele jaren. Dit is geen unieke feature van ZFS.

In geval van RAID1, als disk 2 uitvalt, terwijl disk 1 nog leeft, dan krijgt disk 1 heel veel reads te verduren. De vervanging van disk 2 krijgt veel writes te verduren. Maar daar kun je ook een non-SMR voor gebruiken. Het ligt dus voor de hand dat je een andere cold spare wilt dan een SMR (e.g. 2-6 TB WD Red).

RAID0 gaat meer over throughput ipv availability. Gaat het enkel om de grootte, kun je net zo goed JBOD gebruiken.

Bij RAID5 en andere varianten maakt het vziw ook niets uit.

Gaat het enkel om de grootte, kun je net zo goed JBOD gebruiken

Nou niet net zo goed. Beter. Met een raid 0 array heb je afhankelijk van het aantal disks N, N*x kans op failure van de gehel array. 1 disk kapot is bye bye data. Bij JBOD moeten ze dan allemaal defect gaan. Het is letterlijk alles bij elkaar opgeplust en dat op 1 volume mount geplakt.

Bij RAID0 wordt de data verspreid over de twee disks. Afhankelijk van je use case, kan dit hogere read/writes betekenen.

RAID is bovendien geen vervanging voor backups.

Is zo. Maar het punt was. Als het je gaat om grootte kun je beter JBOD gebruiken. Raid0 is echt alleen leuk als je de snelheid nodig hebt. Scratch disk met video editting bijvoorbeeld. Anders is het vragen om problemen.

Je verhaal klopt natuurlijk, alleen het gaat op voor alle schijven, niet alleen smr.

@Aikon & @NimRod1337

Met SMR is het veel erger dan met vergelijkbare schijven die een andere techniek gebruiken.
SMR is helemaal gericht op lineair lezen en schrijven. Nu zou je kunnen zeggen dat "gewone" draaischijven ook veel beter presteren als je ze lineair gebruikt in plaats van "random", maar bij SMR is dat nog effect veel groter.
Alsof je over de snelweg probeert te rijden terwijl iemand iedere 30 seconde je rem vol intrapt. Dat is vragen om ongelukken.

[Reactie gewijzigd door CAPSLOCK2000 op 18 april 2020 15:46]

Zou het ook voor de Red Pro's gelden?

Om nou in ene 2x 8TB aan te gaan schaffen wordt wel een kostbaar alternatief voor 2x 4TB.
Wel lekker veel ruimte, dat dan weer wel.

WD Red schijven zijn juist voor een NAS bedoeld dus die belazeren de kluit enorm, de rest zijn voor zover ik weet geen NAS schijven. Beste is Western Digital in het vervolg laten liggen ongeacht de mooie verhaaltjes die er rond gaan dat ze zo betrouwbaar zijn... ehm niet dus.

Maar dan blijft er niet zoveel over aan keus.

Als je een pool disken hebt dan draai je waarschijnlijk geen mirror. Waarom heb je het dan over resilver. Het in dat geval rebuilt. En elke hardware raid controller die in een moderne computer past doet dat terwijl de raidset gewoon te gebruiken is. Afhankelijk van de instellingen en welke prijsklasse de controller is kun je aangeven wat prio heeft. Rebuilt of use.
En ongeacht welk type of raid je gebruikt. Op het moment dat er 1 disk defect raakt na een aantal jaren loop je een groot risico dat de rest ook gaat omdat deze nu hard aan het werk moeten.
Het je een intel onboard raid controller. Dan heb je een software controller die niet in je OS draait maar op het moederbord. Kom je achter als je met unix of vmware gaat spelen.

Je zou je even moeten inlezen in ZFS, daar spelen een aantal dingen net iets meer of net veel minder dan bij traditionele RAID.
Een resilver onder ZFS is wat jij een rebuild (met een D trouwens ) noemt onder traditionele RAID. De poster benoemt het correct.
Uiteraard is een VDEV ook nog altijd bruikbaar tijdens een rebuild bij ZFS, dat is niet zo bijzonder.

Hier iemand die specifiek red heeft gekocht voor dualbay nas niet zo'n nette actie dit.

Wat ik niet begrijp is waarom ze die read errors beginnen geven. DAT zou al helemaal niet mogen en daar heb ik eigenlijk nog niet van gevonden wat daar de oorzaak van is. Performance penalty tot daar aan toe, maar ze moeten toch betrouwbaar de data terugleveren zoals een non-SMR disk... Ik heb een van die artikels gelezen en vind het heel kwalijk dat die ZFS array na een paar uur een disk er uit moet trappen omdat ie niet meer mee doet.

[Reactie gewijzigd door HyperBart op 19 april 2020 15:43]

Alleen langzamer. Het bijt vooral een beetje dat sommige van deze schijven werden aangeprezen als bedoeld voor NAS terwijl ze daar juist het minst geschikt voor zijn.

Alleen langzamer. Het bijt vooral een beetje dat sommige van deze schijven werden aangeprezen als bedoeld voor NAS terwijl ze daar juist het minst geschikt voor zijn.

In hoeverre een smr schijf geschikt is voor een NAS hangt heel erg af van het doel van het NAS. De performance penalty van smr speelt vooral een rol bij random schrijfacties, waarbij er veel ongerelateerde kleine stukjes data worden weggeschreven. Er zijn genoeg toepassingen van NAS-apparaten die een dergelijke gebruikspatroon niet hebben, bijvoorbeeld een centrale opslag van bestanden die veel geraadpleegd, maar zelden gewijzigd worden. Bij dergelijke toepassingen merk je vrijwel niets van het feit dat je een smr schijf hebt en is de extra GB-per-euro een belangrijkere factor.

[Reactie gewijzigd door Rannasha op 17 april 2020 17:11]

Helaas is er hier geen sprake van extra GB-per-euro. De nieuwe, tragere SMR versie is even duur of in sommige winkels zelfs duurder dan de oude, snellere versie.

pricewatch: WD Red (64MB cache), 4TB
pricewatch: WD Red (256MB cache), 4TB

[Reactie gewijzigd door bertware op 17 april 2020 17:48]

De nieuwe, tragere SMR versie is even duur of in sommige winkels zelfs duurder dan de oude, snellere versie.

Precies!

While SMR drives are cheaper to manufacture than PMR drives, none of the savings is being passed on to customers as far as we can tell.

Bron: https://www.extremetech.c...thout-informing-customers

Plus dat je van tevoren niet weet wat je koopt, omdat het niet uit de verpakking is op te maken.

Je kan ze herkennen aan het typenummer (in alle geval de 4 en 6TB).
De originele WD40EFRX/WD60EFRX reeks wordt echter bij veel winkels niet meer aangevuld, of is reeds niet meer te krijgen. Binnenkort zal enkel nog de tragere WD40EFAX/WD60EFAX versie te vinden zijn. Je kan ze ook herkennen aan het cachegeheugen, wat vergroot is van 64Mb naar 256Mb om het prestatieverlies door SMR wat te beperken. (Het cachegeheugen niet verwarren met de duurdere WD Red Pro reeks, die ook 256mb cache heeft maar bij mijn weten geen SMR gebruikt, 5 jaar ipv 3 jaar garantie heeft en die aan 7200rpm ipv 5600rpm draait)

Dat is in mijn boekje gewoon oplichting ..

Je kan je NAS er ook op inrichten. Ik heb hier een ZFS mirror met twee SMR 5TB schijven voor de grote bestanden zoals Foto's en Video en een ZFS SSD mirror voor de random r/w workloads zoals software development, logging databases enz.

Dan merk je er dus helemaal niks van.

[...]


In hoeverre een smr schijf geschikt is voor een NAS hangt heel erg af van het doel van het NAS. De performance penalty van smr speelt vooral een rol bij random schrijfacties, waarbij er veel ongerelateerde kleine stukjes data worden weggeschreven. Er zijn genoeg toepassingen van NAS-apparaten die een dergelijke gebruikspatroon niet hebben, bijvoorbeeld een centrale opslag van bestanden die veel geraadpleegd, maar zelden gewijzigd worden. Bij dergelijke toepassingen merk je vrijwel niets van het feit dat je een smr schijf hebt en is de extra GB-per-euro een belangrijkere factor.

Hmm nee random write gaat juist vele malen sneller, mits je binnen de cache (vaak 100GB) blijft. Het gaat juist mis bij sustained writes.

Seagate Archive HDD 8TB - Crystaldisk 3.0.3 x64:
seq 199.4/189
512K 50,95/128.5
4k 0.588 / 12.51
4k32 1.938 / 10.47

Seagate Ironwolf HDD 8TB - Crystaldisk 3.0.3 x64:
seq 240.9/237
512K 73.67/156.6
4k 0.926 / 2.954
4k32 3.255 / 2.954

Wanneer er té lang té veel wordt geschreven dan moet de schijf intern gaan swappen en dan krijg je snelheden vergelijkbaar aan duplicatie van bestanden binnen dezelfde schijf/partitie.

[Reactie gewijzigd door sdk1985 op 18 april 2020 02:02]

voor NAS boeit snelheid toch niet? is vooral opslag/archiveren.

Dat kan voor sommige zo zijn. Echter voor mij niet. Ik heb een 11x4TB raidz3 (freenas) setup, die ik ook gebruik om gewoon games vanaf te spelen. Voor mij mij is het een alternatief voor de hdd die ik voor heen gewoon in me pc zou hebben.

Op mijn NAS staan anders gewoon datastores van mijn ESXi omgeving. Voldoende random R/W, waarbij SMR dus killing zou zijn. Niet elke nas is in gebruik voor WORM of WORN data.

Haha, heb je al gehoord van 10GbE?

Hangt er van af, als dit een NAS is met films, foto’s en muziek zijn SMR drives ideaal. Is het een NAS met een zwaargebruikte database erop, dan niet.

Voor toepassingen met veel random write-acties, zoals bij nas-systemen het geval kan zijn, blijven de smr-schijven minder geschikt.

Mooi dat WD dat dan toepast op z'n RED serie

Als de harde schijf (RED) gewoon volgens specs werken, dan is er niets aan de hand. Het maakt dan helemaal niet uit wat er binnen in de harde schijf gebeurd. Wat je wel ziet is dat men zich niet aan bepaalde door de fabrikant voorop gestelde eisen houd, waardoor de harde schijven out-of-specs draaien. Bijvoorbeeld te veel harde schijven van een bepaald type in één systeem.

Ik vind het artikel net iets te weinig achtergrond informatie hebben om hier een goed oordeel over te kunnen gegeven.

[Reactie gewijzigd door _Dune_ op 17 april 2020 18:58]

Lees dit dan maar eens,
https://www.golem.de/news...-hinweis-2004-147896.html

of de engelse links :
https://www.tomshardware....ed-hdds-use-slow-smr-tech

https://www.smartmontools.org/ticket/1313

Ik heb voornamelijk het stuk gelezen van Tom's hardware, toch bekruipt mij het gevoel dat de problematiek voornamelijk ontstaat in gevallen, waar de fabrikant de harde schijven niet voor bedoeld heeft. De RED-series zijn puur bedoeld voor small-business en home-use. Ik lees over RAID-array's, tussen de regels doorlezende, het idee heb dat het om grotere array's gaat dan home en small-business en ZFS, wordt dat ondersteund? Dan kun je zeggen, ja maar..

Als een fabrikant iets niet ondersteund of garandeerd, dan kun je kijken of het gaat werken, dan heb je geluk als dit het wel doet, maar gewoon pech als dit niet het geval is. Ik heb verschillende RAID-sets in mijn lab, bestaande uit drie ESX hosts, een NAS en twee SAN's. Allemaal harde schijven van 1TB en 2TB WD RE4-GP de grootste array bestaat uit 12 schijven. Die doen uitstekend waar zij voor bedoeld zijn.

Sommige van deze harde schijven komen uit grote RAID array's en deden daar hun kunstje ook uitstekend, maar daar zijn zij ook voor gebouwd, dus nogmaals ik wil weleens weten in welke omstandigheden men nu echt problemen ondervindt met de besproken harde schijven.

Heb ook het originele artikel gelezen en ook ik krijg het gevoel dat hier appels met peren wordt vergeleken. Bovendien wordt er wel hele erg negatief gedaan over SMR.

Nu ben ik geen merkadept en gebruik ik zelf meestal wat er goedkoop voorhanden is. En ik heb dan ook geen voorkeuren en vind het terecht dat fabrikanten op nalatigheid wordt gewezen. Maar in dit geval vind ik het wel erg vergezocht worden.

Als je de specsheet van de WD Red drives bekijkt is het beoogde doel Home and Small business use met een maximaal aantal drives in een NAS van 8. Als je kijkt wat de gemiddelde SOHO gebruiker wil en gebruikt dan is dat een QNAP of een Synology om de bestanden van het bedrijf op op te slaan.

Tendentieus wordt het artikel al helemaal als ze het hebben over "possible data loss" bij "rebuilding a ZFS array" - ik weet niet welke SOHO NAS een ZFS array heeft maar ik denk de meeste niet. De QNAP SOHO lijn gebruikt geen ZFS. De Synology SOHO lijn gebruikt ook geen ZFS maar hooguit een proprietary zusje. Bovendien hoort iedereen die ook maar iets met een drive array doet ook een B-A-C-K-U-P te hebben dus hoezo bang zijn voor data loss wegens problemen gedurende resilvering in een SOHO omgeving?

Bovendien blijken er naast de "standaard" WD Red schijven ook WD Red Pro schijven te bestaan. Die neem ik aan dan geen gebruik maken deze shingled techniek. En voor enterprise toepassingen hebben ze weer een heel andere lijn.

Dat je het prettig zou vinden om de verschillen tussen de verschillende typen drives wat helderder te hebben, dat kan ik begrijpen. Maar om te beweren dat er sprake is van oplichterij, dat gaat mij echt veel te ver.

Synolgy en Netgear gebruiken BTRFS.
Dit lijkt in gedrag op ZFS, dus dit kan zeker een probleem zijn in SOHO situatie.

Qnap gebuikt momenteel Ext4 en op hun enterprise producten ZFS, maar dit jaar brengt een nieuwe versie van hun software uit en dan brengen ze ZFS naar hun consumenten NAS-systemen.
Ze moeten wel want ze willen BTRFS gebruiken.

Van de archive-schijven is bekend dat het SMR sterker toen dien geintroduceerd werden waren er documenten van de fabrikanten waarin dit stond aangegeven. Daarnaast waren er documenten waarin werd uitgelegd waarom ze niet als normale schijf geschikt zijn.
Maar blijkbaar geldt dat niet meer, wat natuurlijk onzin is.

Ik koop wel lekker de veel duurdere WD DC310 serie (de oude Ultrastars van hgst) herrie maar betrouwbaar of Tohsiba N300's hebben het ook niet.

De Red series is bedoeld voor NAS en RAID-gebruik, men geeft het specifiek ook aan:
https://shop.westerndigit...al-drives/wd-red-sata-hdd

Of die RAID-laag nu verzorgd wordt door ZFS of software RAID is irrelevant.

Dat klopt helemaal, al-hoe-wel er in de RAID implementaties ook verschil kan zitten, ongetest vanuit fabrikant is gewoon geen garantie, maar.. welke RED-serie heeft men gebruikt de Pro of de non-pro. De non-Pro is up-to 8 drives per RAID set en de Pro up-to 24 drives, voor het zwaardere werk zeg maar. Ik mis overal de details zowel n het artikel hier als in de bronnen: Wat hebben ze exact hoe gebruikt? Zonder deze details is het met modder gooien.

[Reactie gewijzigd door _Dune_ op 19 april 2020 18:55]

Inderdaad:

Designed For NAS

Desktop drives aren't purpose-built for NAS. But WD Red drives with NASware 3.0 are. Our exclusive technology takes the guesswork out of selecting a drive. We can help you find the perfect storage for your NAS system.

Wat ik niet snap aan dit verhaal... SMR is bedacht om meer data op 1 platter te krijgen.
Echter we hebben het hier over relatief kleine disks van 2TB en 4TB, die capaciteit ging toch met SMR ook al gemakkelijk? Of is het gewoon een productiekosten plaatje en maken die HD boeren een 4TB single platter SMR HDD om zo kosten te besparen?

Seagate heeft iig schijven met 1 enkele platter (bijna gekocht maar toch maar niet) die SMR zijn. Dat was normaal inderdaad niet te halen op 1 platter. Probleem volgens reviews is het ineens inzakken van het schrijven. Met 4TB zijn het 2 platters. Dit bespaart inderdaad op de kosten. Alleen maken ze de nieuwere "betere schijven" met een klap meer cache om tragere schrijven op te vangen ook gelijk een klap duurder dus de enige die er iets van merkt is de producent op de winstrekening.

Die extra cache is niet alleen zoals "altijd" om slechte performance n beetje op te krikken,
maar moet ook groot genoeg zijn om 1 "shingle" (of hoe t ook heet) te kunnen bevatten,
zodat die in 1 keer weggeschreven kan worden, wat vereist is bij SMR.
Ook hebben die schijven geloof ik wat meer administratie bij te houden van wat waar staat.

Zo kan cache grootte overigens helpen te beoordelen of n schijf SMR of PMR is, alsmede het gewicht (aantal platters, en daarmee hoeveel GB/platter, en daarmee of PMR dat aankan).
Mss geeft geluidsproductie/verbruik ook hints over het aantal, maar ben ik vergeten.

[Reactie gewijzigd door N8w8 op 18 april 2020 15:00]

Ik denk dat je het wel snapt. Sommige shops bieden nu al geen EFRX drives meer aan onder de 8TB, dus er zal een moment komen dat de 'kleinere' EFRX drives EOL worden.

Yep, je slaat de spijker op zijn kop. Platters, voor diegene die het niet weten, zijn de ronde schijven waar de data op staat. Des te minder platters, des te minder kosten. Niet alleen in fabricage kosten maar ook gewicht (transport).

Zoals alles business, is dit een kostenbesparing actie.

Gaat dit nog grote gevolgen hebben? Denk dat bedrijven hier niet blij mee zullen zijn omdat ze best wat geld in de HDD gestopt hebben maar niet de geleverde prestaties leveren die werd gemeld bij aankoop van de HDD.

Nee, bedrijven betalen extra voor enterprise disken waar men niet de kantjes afloopt voor wat extra opslag, net iets meer snelheid of toch net iets goedkoper te kunnen zijn.
Die disken zijn dan ook 50% duurder maar dat heeft enterprise ervoor over, consumenten niet.

Om een SSD als voorbeeld te nemen, je kan geen over provisioning doen, je kan een beetje en je kan 30% gaan doen, dat wil zeggen dat je SSD in werkelijkheid 30% meer opslag heeft dan dat je kan gebruiken, dat kost geld en dat krijg je aan een consument heel moeilijk verkocht.

LoL. Net als met alles zullen de US gebruikers wel 'n schadevergoeding krijgen. In de EU kunnen we 't uitzoeken. Net als met alle 'schandalen' met Apple, Volkswagen en noem maar op.

Van beiden valt wat te zeggen, de compensatie die je soms in Amerika krijgt zijn van de zotte natuurlijk maar dat wij doorgaans 'niets' krijgen behalve een pardon is ook altijd erg zuur

Een excuus krijg je zelfs niet. En al sje erover moppert wordt je op fora terechtgewezen 'dat je maar beter de documentatie had moet en lezen' en 'dat je het zelf gekocht had' en dat 'je dat had kunnen verwachten'.
Zijn Nederlanders van die masochisten, denken ze dat ze alleen leuke dingen krijgen als ze de leverancier de vrije hand geven, of zijn het trollen uit de marketing?

Omdat mensen daar actief de rechter opzoeken en de mensen hier passief wachten tot het voor ze opgelost wordt.

En dat gebeurt dan niet en dan heeft de EU het gedaan natuurlijk, want anders zouden we zelf verantwoording moeten nemen en dat is eng.

[Reactie gewijzigd door Flagg op 17 april 2020 18:45]

Ik dacht dat het in geval van de Seagate Archive HDDs al een paar jaar bekend was. Ik heb zelf al jaren zo'n schijf in 8TB uitvoering en inderdaad zeker niet geschikt voor random writes. Voor die schijf zijn ooit aanpassingen in de Linux kernel doorgevoerd vanwege die techniek, omdat de kernel "dacht" dat de schijf op sommige momenten kapot moest zijn, omdat de schrijfprestaties zo variabel waren.

In ieder geval in 2015 al een review die aangeeft dat die schijf gebruik maakt van SMR: https://www.storagereview...te-archive-hdd-review-8tb en de problemen die dat onder Linux veroorzaakte: https://serverfault.com/q...nd-repeated-sata-timeouts

[Reactie gewijzigd door staaldui op 17 april 2020 17:23]

Inderdaad, ik denk dat fabrikanten (of wellicht alleen Seagate) nu gewoon een lijst hebben gegeven van álle SMR-modellen, ook bij de disks waarbij het al vanaf het begin officieel bekend was.

Oh lekker dan.

Ik Heb een Seagate ST5000LM000-2AN170

Dan maar hopen dat ik niet zoon SMR harddisk heb. Bestaat er ook een lijst met alle harddisks die gemaakt zijn mijn deze SMR technologie.

[Reactie gewijzigd door LEX63 op 18 april 2020 08:30]

Oh lekker dan. Ik Heb een Seagate ST5000LM000-2AN170

En ben je dan ontevreden over de performance van die disk? Of was het je nog nooit opgevallen dat hij wellicht trager is dan je had mogen verwachten? Asl dat zo is zou ik me er gewoon niet te druk over maken.

Gelukkig werkt hij nog goed,

Als ik dit soort berichten lees dan word ik daar niet vrolijk van.

ik gebruik hem ook weinig hij staat altijd afgemeld bij Windows. Ik activeer hem alleen wanneer ik hem nodig heb, hij heeft bijna 8000 uur gedraaid volgens Crystal DiskInfo.

Tja het is toch altijd een gok als je een Seagate harddisk koopt, je moet geluk hebben.

De reputatie van Seagate heeft in het verleden behoorlijke schade opgelopen. Ik ga er dan ook vanuit dat ze van deze fouten hebben geleerd.

[Reactie gewijzigd door LEX63 op 18 april 2020 08:40]

Als je WDs specs erbij haalt zeggen ze juist dat de nieuwere (SMR) versies sneller (kunnen) zijn:

bijv de 4TB versie..

oude 64 cache model 150MB
nieuwe 256 cache model 180MB

Ik vind het niet netjes dat ze het niet gewoon communiceren. WD heeft het bijv bij aandringen pas gezegd dat bevindingen correct waren. Daarvoor hielden ze de boot af..

Daarvoor hielden ze de boot af..

Ze hielden niet eens de boot af, maar gaven expliciet de boodschap dat ze over dat soort zaken aan consumenten geen mededelingen doen - punt.

De humor daar is dat het eigenlijk al net zo goed is als het feit bevestigd krijgen. Want anders zou er niets zijn om achter te houden en zou de werkelijke strekking al overeen hebben gekomen met 'wat er op de doos staat.' - dus waarom dan moeilijk doen?