Western Digital smyger ut sämre teknik i NAS-hårddiskar

Info finns i user manual (sid 9):
https://www.seagate.com/www-content/product-content/ironwolf/...
https://www.seagate.com/www-content/product-content/ironwolf/...
https://www.seagate.com/gb/en/internal-hard-drives/hdd/ironwo...

Jag har 2st WD red 4TB i min NAS, men de köptes 2015, samt en WD Red 4TB som "mellanlagring" i den stationära, köpt 2019. Kan inte säga att jag direkt märkt av lökig prestanda i någon av enheterna, men det här är ändå jävligt oärligt och tarvligt av dem, och det vore ytterst intressant att få veta vilka serier som är påverkade av dumheterna. Jag som alltid har hållit WD hlgt jämfört med andra tillverkare

Åhh, tack! Dagens guldstjärna.

Det hade jag missat, jag kollade data sheets bara.

Samma här. Köpte 8 st 4TB första halvåret från 3 olika leverantörer, alla 8 var EFRX.

@pv2b: Du har helt rätt i det du skriver, men: SMR är väldigt fel val för RAID-bruk. En rebuild av en stor array kommer bokstavligen ta evigheter om man har SMR-diskar, och det när din array redan är försvagad. Det kan gå riktigt illa.

Det finns också fall där SMR-diskar kan provocera fram fel, bl.a. med ZFS, p.g.a. det går för långsamt så det blir timeouts och dylikt.

SMR har definitivt sin plats ja, men inte i en RAID.

Är det däför mina nya 4TB tuggar mycket mer än de gamla RED-diskarna. De gamla var mycket tystare under drift med dova ljud från sökningarna, medans de ny EFRX är mycket mer aggro och låter avsevärt mer under drift.

Det jag inte förstår är vad det är för något med just SMR-teknik som gör att det blir dåligt specifikt för RAID-rebuilds. En RAID-rebuild är ju i princip en enda lång sekventiell skrivning till disken som ska byggas om. Detta är inte något som SMR-teknik rent teoretiskt sett ska göra dåligt. Har jag missat något? Jag vet uppriktigt talat inte, men det verkar ju inte finnas något fundamentalt med själva tekniken som gör den olämplig för RAID.

Enligt Western Digital själva så ska inte det vara något problem att bygga om RAID-arrayer med SMR-diskar rent generellt. Sedan kan det ju vara så att vissa RAID-implementationer inte är bra på att hantera SMR-diskar av någon anledning som jag inte känner till, men är det verkligen diskarnas fel i det läget?

Oavsett så är det ju bra att diskar som använder SMR-teknik är tydligt uppmärkta så att de som kör RAID-implementationer som inte lirar bra med SMR-diskar kan undvika dem. Problemet med att tillverkare väljer att göra på det här sättet blir att takeawayen blir "SMR är dåligt" snarare än "se till att din applikation fungerar väl med SMR-diskar".

@pv2b:
SMR diskar klarar ofta inte raid rebuilds, då rebuilden ska verifieras har disken internt skyfflat om datan redan. Så rebuilds som ska ta 4 timmar tar 48 timmar och slutar med felmeddelande och misslycka rebuild.

Men på vilket sätt är detta ett problem specifikt med SMR-teknik? Det där kan lika gärna vara en dålig implementation antingen på disksidan eller på RAID-sidan.

@pv2b:
Klart det finns filsystem som är resistanta mot sådant, ZFS specifikt, och SMR diskar som är bättre kompatibla och inte. Saken med NAS diskar och specifikt WD Red var just bra firmware och implementation som fungerade med allt. En pålitlig plattform designad för NAS bruk och Raid.

Nu har de bytt ut 6TB och lägre från CMR till SMR med tjuvknep i firmwaren som gör dem nästintill oanvändbara i Raid bruk. Man kan inte ersätta felande äldre CMR diskar med dessa nya SMR diskar i existerande raid-setups till exempel.

Så ja SMR i det här fallet är ett problem.

det kanske förklarar många som lider av samma synology problem som jag att den ALDRIG blir klar när den kollar att data stämmer överens med diskarna. det har lett till att jag stängt av den funktionen. kom upp till över 90% varje gång och sedan stannade. på synology forumet är jag knappast ensam om detta. kanske ska kolla upp om alla kör wd red.

@osgorth: Jo precis, det är samma slutsats jag också drar. Det SMR egentligen är dåligt på är slumpmässiga skrivningar, eftersom skrivhuvudet "skriver sönder" data runt om, vilket gör att man måste skriva om en massa data runt om, så jobbar man runt detta genom att mappa om sektorer på något smart sätt.

Det jag inte förstår är varför man i så fall skulle se samma problem på rent sekventiella skrivningar. Det borde ju bara vara att skriva en hel zon i taget. Att bygga om en RAID är ju typexemplet på något som borde vara en exakt 100% sekventiell skrivning. Är det dåligt optimerad firmware i hårddiskarna, som egentligen borde kunna hantera det här väldigt specifika mönstret på ett smartare sätt?

Därav min slutsats att detta måste vara ett implementationsproblem som gör att detta funkar dåligt, inte ett problem med SMR i allmänhet. Eller så kanske det är så att när man bygger om en RAID så måste man regelbundet uppdatera en datastruktur med något RAID-metadata eller något liknande vilket avbryter de sekventiella skrivningarna och det är det som faktiskt orsakar den pessimala prestandan? Nu är jag långt ute och gissar. Men i så fall så känns det som att det är det scenariot man får försöka optimera, antingen i RAID-kontroller/mjukvara eller i firmware för diskar.

Det hade varit spännande/intressant att se en benchmark där man helt enkelt gjort en ren dd if=/dev/urandom of=/dev/sda och mätt skrivprestanda över tid, helt utan filsystemsoverhead. Äger tyvärr ingen SMR-disk själv att testa med.

P.S. Denna artikel var intressant: https://lwn.net/Articles/720226/

Ja, precis så har jag fattat det hela också.

Ja, "borde" är rätt ord.. Det fungerar inte så idag, men helt klart borde det gå att lösa via firmware och/eller intelligent filsystem.

Den var riktigt intressant t.o.m. - tackar!

Det visar ännu tydligare att det är mjukvaran som sätter stopp. Jag tycker följande passage är tankvärd:
Spreading metadata across the disk was invented some 30 years ago, maybe it is time to revisit that idea, he said. It is based on the explicit assumption that the cost of random reads is high, but also the implicit assumption that the cost of random reads is the same as the cost of random writes, which does not hold for SMR.

Det förklarar en hel del, dock inte det explicita fallet med RAID.
I en RAID skulle du behöva intelligens som gör att när du genomför en rebuild måste kontrollern/filsystemet buffra upp en hel schingle i taget innan den committar till disk. I dagsläget läser och skrivs det block för block (i regel 4KB) vilket sannolikt är vad som skapar problemen. Det är tekniskt fullt möjligt, men jag tror inte jag sett någon lösning på detta ännu.

Jag har tyvärr ingen SMR-disk kvar själv, annars skulle jag gärna bidra med tester. Jag hade två st Archive 8TB, men de har bytts ut mot något rappare Ironwolf.

Detta var ju långt över min kunskap iaf! Spelar detta någon roll om man inte kör raider osv utan bara har en disk för lagring?
Och vilka diskar är bäst egentligen? jag har kört wd red ett tag men har massa smådiskar som jag skulle vilja ersätta med en stor. Ska man fortsätta på red eller ska man byta märke?

Seagate IronWolf.

Nej, så länge du bara backar upp lite familjefoton och en och annan långfilm spelar det ingen roll. Skall du backa upp tiotusentals små loggfiler varje timme så kanske du skall ha något annat, se nedan. (men det beror även vilket filsystem du använder)

Skall du ändå köpa en stor disk kan du lika gärna köpa 8 TB eller mer och då berörs du inte av detta, de diskarna är fortfarande CMR. Vill du ha 4-6 TB skulle jag tagit en Ironwolf.

Varför skulle det bli vakuum?

De faktorer som kan få helium att "vilja" smita ut är:
1. Invändigt övertryck, om hårddisken blir varm. Då skulle en mindre del helium kunna slinka ut tills tryckskillnaden minskat. Ett mjukt membran som minskar tryckskillnaden kan också förebygga detta.
2. Osmotiskt tryck. Heliumhalten är mycket högre invändigt än utvändigt, varför en del helium kan tänkas försöka ta sig ut för att minska skillnaden i koncentration. Jag är tveksam till att denna kraft skulle kunna vara så stark att det på fem till tio år uppstår något som kan kallas för vakuum (absolut tryck nära noll).

Enterprise-disk har inte magiskt bättre prestanda än konsumentdisk. De första SMR-diskarna dök upp i det segmentet, dock tydligt markerade som sådana. Det som skiljer åt är gränssnitt (ofta men inte alltid SAS istället för SATA), firmware, saker som att de är mer vibrationståliga i chassin med många diskar tätt packade, och liknande. Köper man dessutom disk som är OEM-brandad att funka till en viss serverserie så har man också vissa garantier för att grejerna funkar väl ihop. Men precis som med konsumentdisk så är det viktigt att veta vad man köper.

Vill man ha hög prestanda köper man inte hårddisk. Man köper SSD. Jag ser mindre och mindre hårddisk i de system jag ser på jobbet. Det är främst något för data-arkivering och backup.

Det här överskred min nivå, känner jag. Undrar om någon kunnig kan ge råd här. Jag sitter nu på en DS918+ med 2 st EFRX på 4 TB i RAID 1 och så finns det 2 tomma platser. Nu har diskarna fyllts till 87 % och jag hade tänkt utöka med ytterligare 2 diskar i partitionen. Bör jag:

- Utöka med 2 st ytterligare 4 TB EFRX diskar och konvertera till RAID 5/6? Ser att de fortfarande finns att köpa i vissa butiker på nätet. Problemet med detta som jag ser är när diskar framöver dör - måste jag inte då behöva leta upp 4 TB CMR-diskar, med risk för att de inte ens finns på marknaden då? Hur är det att kombinera med andra märken än WD (om det finns andra aktörer med 4 TB CMR)?

- Utöka med WD Red 8 TB (för att garanterat få CMR-diskar) och para dessa med mina existerande 4 TB-diskar i RAID 5/6? Detta leder såklart till att mycket utrymme inte ens utnyttjas på diskarna fram tills att 4 TB-diskarna byts ut...

Kanske finns alternativ som jag missar här?

Edit: Läste just på om SHR. Verkar vara rätt väg att gå att köpa 2 st 8 TB och låta dem rulla tillsammans med mina befintliga 4 TB-diskar i SHR. Någon som vill bekräfta om jag fattar rätt? 😊

Japp Osmotiskt tryck, är det jag tänker på.
Vet inte hur lång tid det tar att tömma disken, det räcker nog garantitiden ut, men vad händer sedan?

Ja, SHR ger dig mer utrymme i det fallet.

Men du kan inte konvertera RAID1 till SHR, så du får skyffla över det du har på 4orna till en ny 8a, och sedan ta bort poolen och skapa en ny med SHR, sedan kopiera tillbaka allt för att till sist utöka med 8orna.