WD Red VS Seagate IronWolf

@FinePlayer: Så länge du bara har den som ren lagring så kommer du inte märka någon skillnad, men har du något som krävs att du skriver och läser ofta så kommer det till slut bli komplikationer. På samma sätt som om du har en SSD utan cacheminne, fungerar bra tills cacheminnet blir fullt och då går det väldigt långsamt.

Sen verkar många vara missnöjda med just den versionen av WD Red diskarna jämfört med den tidigare serien som inte var SMR.

Man skall inte glömma att SMR-diskarna beteende blir allt bättre med diskgenerationer.

Köpte en Segate 10TB externdisk (okänt vilken disk i denna) och måste säga att den sköttes sig väldigt bra och körde inte i 'väggen' på samma sätt som Seagate archivediskarna tidigare när mycket småfiler skrevs på olämplig filsystem som NTFS. - och snabb är den också - ca 260 MB/s sekventiell skrivning vid OD, 165 MB/s vid ID och genomsnitt från början till slut 221 MB/s läsning och 218.3 MB/s vid skrivning - genomsnittlig söktid baserad på 1000 random sökningar 13.07 ms - detta kördes via USB3 och inte direkt mot SATA-anslutning och med gnome-disk i Linux.

(Seagate har en dubbel-huvud disk (14 TB-disk som visas som 2*7TB logiska diskar på samma anslutning) - den kommer att helt fylla upp SATA-bussen i kapacitet i överföring...)

Provade faktiskt med NTFS först 10TB-disken och en typisk grej att framkalla 'väggen' och det går snigellångsamt var att kopiera en mycket välanvänd windows-systemdisk rätt av där det lätt kan husera över en miljon filer varav väldigt många är väldigt små (och gömmer sig under AppData) och en hel del som är hårdlänkade - mycket grottande med 'modify' på $MFT - det som SMR-diskar 'hatar' och tycker att det är det värsta som finns vid skrivning - dvs. skriva om och om igen med lite olika data på ungefär samma fläck på disken. alla filsystem har mer eller mindre det problemet att metadatat ligger på samma ställe och hela tiden uppdateras - dock på BTRFS alltid på nya sektorer och modifierar inte de gamla.

Där brukar NTFS 'stanna' vid ca 50-70 GB överfört och då lämpligen pausar man kopieringen i typ 20 minuter innan man kopierar vidare.

med 10TB externa USB-disken - inga alls sådana tendenser, så någon form av svart magi har de helt klart gjort.

Jag kör normalt alltid BTRFS på mina externa backupdiskar då de är mycket mindre påverkad av SMR-disk av sin COW-skrivsätt och brukar ha minst en faktor 10 till mer i skrivmängd innan det blir långsamt gentemot NTFS vid småfiler. - Den viktigaste orsaken till valet är dock att den verka vara mycket mer tålig mot sladdglapp och andra 'plötsliga' och osnygga stopp utan att filsystemet blir korrupt efteråt och kan monteras igen med mycket små förluster (typ sista 30 sekunder skrivning som värst). Samma sak kan dock inte sägas om NTFS (brrr...). NTFS internt på fasta systemdiskar fungerar (och man har inget val för windows), men externa diskar - nej. använd annat mer kompetent filsystem (finns dock inte för windows då ReFS inte är allmänt tillgängligt längre) eller lägst NTFS på veracrypt där man kan stänga veracryptvolymen först och det avslutas långt innan man rycker strömmen/USB-sladden på disken....

Det jag nu gjorde förutom att kopiera filer från annan disk som skall användas till annat (8TB data, ca 2 miljoner filer) så körde jag samtidigt 'bees' - en blockmässig sidbands-deduplicerare för BTRFS som kördes samtidigt på den nya disken medans jag kopierade filer så fort det gick - och till min förvåning nådde jag inte 'väggen' då trots att kanske 20% av överförda filerna var dubbletter eller partiellt dedublicerbar (dvs. om man ha en diskimage av en disk och samtidigt har en kopia av filträdet i 'klarspråk' för diskimagen så kommer filernas sektorer att kopplas till samma sektorer med samma innehåll i diskimagen eller tvärt om och därmed närmast halvera upptagna utrymmet på disken - sådant läge kan man få med backuphanteraren 'urbackup' som både gör både filträdsbackupper/speglingar och diskimages-backkupper med olika intervall - kör man 'bees' parallellt med det så märks det, mycket, när det gäller att skotta fram ledig diskyta igen) - med 'bees' körande samtidigt med kopierande så får man massiva uppdateringar av metadata av icke sekventiell typ när det hittar dubbletter och i det här fallet med 10 TB disk verkar det inte köra huvudet i väggen.

För att sammanfatta:

För de allra flesta 'konsumentanvändning' med en NAS och det mesta för backup av sina foton, dator och medialager, så kommer SMR-diskars nackdelar vid skrivning knappt märkas gentemot PMR/CMR-diskar av dyrare typ - och för storvolymdiskar > 10 TB så är i stort sett alla diskar av SMR-typ oavsett tillverkare.

Men det finns corner-cases där SMR-diskar inte gör bra ifrån sig och är troligen också modellspecifikt och generationsspecifikt i kombination med använd filsystem eller HW-RAID-kort om det blir riktigt obra med skadad lagring eller bara dålig prestanda typ tar dubbel tid tex. i en disksynkningsoperation efter utbytt disk än med PMR-diskar.

Jag har bara erfarenhet med Segates Archivediskar i NAS och för RAID5 och med mdadm-RAID så går resynkningen hyffsat bra - förmodligen inte med max prestanda men det blir klart och inga dataskador eller utkastad disk ur RAID.

För budgetlagring så fungerar SMR-diskar ala. Seagate Archivediskar i en NAS helt OK. En NAS är också begränsad i skrivhastighet till runt 33 MB/s per disk i en 4-diskars NAS i RAID5 när man håller Ethernetporten mättad fullt ut och redan Seagate Archivediskar kunde skriva med ca 180 MB/s kontinuerligt när man skrev data nära OD (ytterdiameter)

Man skall komma ihåg att SMR-diskar även av första generationen skrev filerna direkt på rätt plats om det går - det var bara ändarna av filerna som inte passar direkt kant i kant med SMR-matrisen utan att det måste skrivas om med tidsödande read-modify-write process, som skickades ned i en PMR-cache area för att senare tas hand om och skrivas till rätt ställe när disken inte har pågående transaktioner i kö.

Har provar lite med BTRFS egna RAID5 och det verkar heller inte straffas hårt med multidiskar och RAID5 med SMR-diskar.

Nu är förvisso BTRFS inte helt SMR-anpassd då det finns osmart hantering och skrivordning när metadata (B-trän som balanseras om) skrivs och därmed fyller på SMR-diskens cache om det görs ofta och mycket vid kontinuerligt skrivande utan paus - och där skulle jag säga faktiskt fungerar bättre mot SMR-diskar än mot PMR-diskar när man har write-cache avstängd då SMR-disken tar hela bajshögen med metadata i osmart skrivordning och lägger det på diskens PMR-cache direkt och sorterar och skriver ut betydligt effektivare senare när det finns tid än en PRM-disk med för lite RAM-cache, tar små tuggor ur bajshögen med metadata i tur och ordning, sektor för sektor (eller om det ta 16 i taget, och kvitterar varenda sektor som är skriven innan det läser in nya) och ser inte helheten i smartare skrivordning.

Har exakt det läget på en HBA i HW-RAID1 och utan egen skrivcache (diskarnas skrivcache avstängd - hårdkodad i firmware av HBA-kortet...) och, ja med nära fylld 8 TB disk med miljoner filer så tar synkningarna ibland en jä*la tid med +18000 sektorer i kö som typ med 1000 sektorer i sekunden betas av och i stort sett stallar burken bara för att det är en PMR-disk - har aldrig sett den här effekten på SMR-diskar tidigare... jo en sak till - detta märktes inte när filsystemet var nygjort och filsystemet relativt tom...

Även om jag upplevs tala mig varm för BTRFS, så finns det saker som kunde ha gjorts bättre... men det finns också en del saker i BTRFS som man, efter att vant sig vid dem, knappt kan vara utan längre trots nackdelarna.

---

Det som tydligen är på tapetern idag är att WD-RED i versionen med SMR-teknik fungerar illa ihop med ZFS och det är corner-case i samband med synkning med långa tider där disken inte svarar (för att dess cache är smockfull och måste nödhanteras och det tar tid, långt över de 7 sekunderna som ZFS har i tålamod innan disken får sparken ut) så kastas disken ut för fort ur ZFS-raiden och problemet är att även nästa och nästa disk kan också kastas ut förbi punkten när det inte finns någon redundans kvar och i det fallet får man problem med seriös korruption och kanske förlorad lagring.

Problemet är att folket som håller på med ZFS och WD:s SMR diskar skramlar väldigt högt och skriker högljudd att SMR-diskar är odugligt skit för RAID-bruk utan någon större nyansering.

Egentligen är det ett mer specifikt problem mellan ZFS och just sagda WD-RED (och potentiellt andra diskar också) med SMR-teknik och här handlar det mer om att laga ZFS så att de kan hantera situationen bättre än att klaga på hårddisktillverkare att de använder SMR alls över huvud taget - för situationen _är_ att alla storvolymdiskar är och kommer vara SMR-diskar långt fram i tiden - lär er (ZFS-folket alltså) hantera det istället för att skylla på andra när det inte går så bra - eller håll kvar på 15krpm 300 GB Seagate SAS Enterprise diskar om man vill ha diskar med förutsägbart beteende - om man tror att det är framtiden!!

Nu har förvisso HD-tillverkarna också saker att polera på som tex. de långa perioderna med inaktivitet/ingen respons (aka frysning) för just SMR-diskarna , men samtidigt skall man tänka på att volymkunderna i molnlagring ofta inte har någon behov av att återuppbygga någon RAID efter en diskbyte - för man byter inte diskar när det gå sönder helt enkelt utan byter först när tillräckligt många diskar i en disk-set gått sönder och redundansen gått under en viss nivå och då byter alla diskar på en gång.