Seagate smyger också in sämre teknik i hårddiskar

Jag håller med att disktillverkarna spelar ett fult spel...

Men, Seagate har benämnt sin implementation av SMR som TGMR åtminstone sedan 2016.
Och TGMR finns specat i "product manual" länkarna, som Blocks and Files tillhandahåller.

Mmm, kruxet är att TGMR verkar vara nåt annat. Flera Ironwolf-diskar använder TGMR och de är såvitt jag erfarit verkligen inte SMR (prestanda är i toppklass).

Märkligt...

I nedan länkad manual till en Ironwolf, står det Perpendicular på sid8,
där det på motvarande ställe i Barracuda-manualen står TGMR.

https://www.seagate.com/www-content/product-content/ironwolf/...
https://www.seagate.com/www-content/product-content/barracuda...

Har jag hittat ett ovanligt exempel?

Det är skrivningar som är långsammare, inte läsningar. De allra flesta lär inte använda fler-TB-hårddiskar för snabba och upprepade skrivningar. Det har man SSD för i dag, och än mer framöver.

I teorin, ja, men för säkert 99 procent av alla användare, nej.

Fult spel!

Jag vågar påstå att de som köper diskar på 4 TB och uppåt har det för långtidslagring av saker, ja. Skriv en gång, läs många. Den typen av "laster". För situationer där man behöver skyffla data fram och tillbaks ofta, så har man SSD:er. När datan är färdigbehandlad och ska arkiveras, så skickar man över det på hårddiskarna.

Minst sagt märkligt ja.. Jag lusläser manualer här nu och ser en skum grej:

I den här manualen: https://www.seagate.com/www-content/product-content/ironwolf/...
under Document Revision History:

Med andra ord så har 1-8TB-modellerna av Ironwolf angivits som TGMR innan 22:a maj förra året. Nu framgår ingenting om vilken tech som används, så det känns minst sagt skumt.

Jag har dessvärre inga små Ironwolf att testa med, mina är 10TB och 16TB.

Jag slits mellan hopp och förtvivlan (något överdrivet:)) om att mina Seagate IronWolf 4 TB ST4000VN008-2DR166 inte är SMR. När man Googlar får man väldigt olika resultat, otroligt förvirrande. Det var i alla fall tur att jag inte köpte WD Red som jag också tittade på.

Min nas har fått två 4 TB IronWolf, stod också med fingret på köpknappen för WD red, puh!

Lagrar också på min 8TB utan raid och sådant.

Att Archive var SMR är väl vida känt. Har kört 8 TB-varianten sedan 2016 och den fungerar fint. Skrivprestandan påverkas inte nämnvärt, det är när man *ändrar* redan skriven data som det kan gå långsamt eftersom den då måste skriva om närliggande spår. Sedan finns det en PMR "cache" och diverse andra funktioner som kör i bakgrunden och minimerar påverkan i praktiken. En helt OK disk för den som behöver billig masslagring.

Däremot såklart fulspel att byta till SMR i diskar som tidigare marknadsförts som PMR...

Vilken butik är det som har den dealen? Hittade inte det i inlägget.

Toppen! Grymt rips!

Det är ingen samarbete - snarare en tekniklösning alla måste använda sig av för öka volymen ännu mer på diskarna.
Att skriva överlappande (shinglat) för att man har begränsning på skrivhuvudena är inget nytt - det hade man på vissa CIQ-bandare för backupper redan under 90-talet och det har alltid varit så att man kan läsa mycket smalare spår än man kan skriva...

Det är ungefär samma orsak varför en cykel ser konceptuellt lika ut sedan början av 1900-talet fast det har tusentals tillverkare och märken av det under senaste århundrandet - av den enkla anledningen att det har visat sig vare den bästa lösningen för 'problemet' och alla avsteg från det har gett mer kortlivade och sämre produkter.

samma sak med HAMR och MAMR - förmodligen är det HAMR som kommer ledande ut då man vet redan idag att det kan skriva mindre punkter än vad som är möjligt med MAMR och även om WD/HGST kommer att kämpa med MAMR ett tag så kommer det ändå sluta med HAMR även för dem (vilket de mer eller mindre redan har brasklappat för)

Har också kört Seagates Archivediskar i NAS sedan de kom ut och märkt väldigt lite av effekterna med SMR i verklig användning.

All skrik och gnäll på att SMR skulle vara dåligt är mer ett politiskt problem som en del vill marknadsföra än ett verkligt problem och ibland undrar jag om de som skriker högst om detta - själva någonsin provat eller om de väsnas efter att bara ha läst databladet och anser att lösningen 'borde' fungera dåligt ock skränar på för att få fler som skränar likt apor i en apflock...

Det är bara att se på den här tråden - bara för att några skriker och gastar om det så tycker helt plötligt väldigt många att det är ett problem med SMR fast de utan att ha vetat det kör på grejorna i kanske flera år. Visst det finns corner case som detta kan ge problem - men då är man ofta en användare på en nivå som borde sukta mot SAS-diskar sedan länge och inte rena konsumentanvändare som bara vill spara en bunt mediafiler i en burk till rimlig kostnad.

---

Jag visste vad jag köpte och visste att det kunde finnas använda/skrivmönster som kan bli problematiska - men i verkligheten sett väldigt lite av det under normal användning och tex byte av en SMR-disk i RAID-5 har inte visat några större problem då det har gått rätt 'straight forward' - trots allt är det rätt 'dum' operation med hyfsat sekventiell skrivning som görs när en RAID5 resynkas i mdadm, som är standard i alla köpeNAS, även de med BTRFS som filsystem.

Jag anser också att BTRFS-filsystem är relativt snäll mot SMR-diskar i och med att den arbetar med chunk (~ stripe) och att COW gör att det inte backar och skriver om gammal data hela tiden utan att det skriver hela tiden mot nya oanvända/frigjorda sektorer för all skrivning och uppdatering - dvs. rätt mycket svans-skrivande omedelbart efter redan skrivna block vilket gynnar SMR-lösningar mycket, medans filsystem som hela tiden skriver om nyss skrivna block och fram och tillbaka som NTFS och dess $MFT så går det inte alls bra på SMR-diskar och kör fort huvudet i 'väggen' prestandamässigt när CMR-delen av diskytan tagit slut.

Stora sekventiella skrivningar är sällan bekymmer för en SMR-disk då datat läggs på rätt ställe direkt med möjligen missar i början och slutet som inte exakt passar in i typisk 32MByte block-indelning och dom bitarna hamnar då i CMR-delen tills det finns tid att lägga dem på rätt ställe när det inte är skrivkö längre.

Om det blir väldigt segt när man kopiera en windows systemdisk till en extern USB-disk i 2.5" storlek med NTFS vid runt 50 GB överfört så är det en SMR-disk - signaturen för SMR är också att armrörelserna på disken kan hålla på upp till en halvtimme efter att man pausat kopieringen från systemdisken eller när det skrivit färdigt och SMR-diskens 'fasa' med NTFS som filsystem är massiva mängder med småfiler som återfinns på en typisk mogen windows systemdisk med över en halv miljon småfiler...

Gör man samma kopiering på samma disk men med BTRFS som filsystem under linux från samma windows-systemdisk så kommer man aldrig se några problem med att 'gå in i väggen' - är det då SMR-disken problem att det blir så just mot NTFS - eller är det kanske inte snarare NTFS som är väldigt dåligt fungerande mot just SMR-diskar och all 'blame' borde istället riktas mot NTFS och att MS inte gjort något åt det eller skapat en modern filsystem för dagens användarmönster även under windows.

Att ZFS folket gnäller på SMR-diskar och det tom. gett filsystem-haverier - borde vändas tillbaka till dem och se till att de lagar sitt filsystem så att skrivstrategierna passar för SMR-diskar bättre, lastbalansera och hittar de cornercase som utlöser problemen så att man inte hamnar där igen. Världen ändra sig hela tiden - adaptera eller dö, det gäller också lagring.

Har en 8 TB segate extern disk med SMR som jag kör borg-backup mot.

Behövde för ett tag sen lite plats för att flytta några stora filer så behövde göra prune på disken för att få lite ledigt...
Tog över 14 timmar att göra detta... så prestanda suger men funkar bara man inte har bråttom.

Vet inte hur de andra gör men segates achivediskar skriver i SMR-area direkt om skrivblocken är tillräckligt stora (typisk 32 MB) och går att passa in i 32MB-rastret kant till kant eller när de kan fortsätta från någonstans i mitten till slutet av blocket - CMR-arean hamnade bitarna som inte gick att passa in snabbt utan dessa fick vänta till disken går i tomgång och det är då en read-modify-write process i typiskt 32 MB-sekvenser startar.

Det betyder att skriva stora filer sekventiellt kontinuerligt är inget problem för den typen av diskar - men att grotta fram och tillbaka på NTFS:s $MFT för småfiler är däremot ett jätteproblem och det byggs upp en jättebacklogg med samma sektorer som skrivs om hela tiden i olika ordningar men utanför cache-fönstret och därmed tappat insikten för skrivsortering att det är samma sektorer som skrivs om upprepande, som nu hamnar på CMR-arean och som senare måste tas och sorteras ut.

Felaktig/idiotisk skrivordning (läs NTFS) och att skriva filer baklänges (från hög till låg LBA-nummer i skrivordning[1]) kan totalt haverera strategierna som tex. SMR använder sig av och det blir verkligen att jobba mothårs - medans stripe eller chunkbaserade filsystem och med COW som hela tiden skriver på nya sektorer och aldrig pilla på det som redan är skrivet (förrän det är ledigförklarat) - klarar sig mycket bättre på SMR även om det där finns saker att förbättra ytterligare även där.

Jag gissar att lagrings-strategier som används av AWS S3, B2 med flera molnlagringstekniker också är snälla mot SMR-diskar då varje skriv och läsoperation är alltid i stora block om många MB och aldrig duttar runt random på 4k-sektor basis.

Sedan i storlager gör man aldrig rebuild av några RAID eftersom det inte är den typen av RAID - utan man kör på diskarna i disktråget tills så många diskar fallit ur att det nått minimum redundans och datat flyttas någon annan stans och så byter man hela disktråget med alla diskar på en gång - man byter inte enskilda diskar och det byggs heller inte för att kunna byta enskilda diskar på enkelt sätt - det gör att egenskaper vid rebuild av RAID inte är prioriterat och därför kan åka på sådana saker som väldigt långa inaktivitestsperioder med SMR när deras CMR-area är full och måste börja nödompacka för att tömma CMR-arean lite och som i ZFS-fallet har gett ödesdigra konsekvenser då systemet tolkat disken som död och kickat ut det i kritiska moment för ZFS och man fått filsystem-haveri.

Alla högvolymdiskar kan man utgå att det är SMR av anledningen att det är SMR som är delar av tekniken att det blir högvolym, så skall man bygga högvolym-lagring så är det bara att köpa läget och lära sig hantera SMR-diskar oavsett fabrikat då det kommer vara lösningen långt framåt tiden.

Skall man ha snabba snurrdiskar med native 512 bytes eller 4kbytes sektorer med PMR/CMR - titta på SAS 10 och 15 krpm 2.5" SFF-diskar (Cheetah hette de förr men verkar gå under namnet exos även idag, Toshiba och hgst har också motsvarande - men de är inte gratis...)

Med mönsterigenkännande tekniker (tänk liknande QR-cod som långa strip) som är nästa steg så kommer det bli ännu större obalans mellan skriv och läsning då man kan läsa flera spår parallellt men kan bara skriva ental/fåtal per varv och behöver då fler skrivvarv för att göra ett fullt spår medans det räcker med ett varv för läsning.

[1]
Det gillar inte ens vanliga PMR/CMR-snurrdiskar då det kraschar helt deras cache-strategi och det kan demonstreras rätt enkelt med ddrescue med optionen att läsa/skriva sektorerna i baklängesordning - tycket man att det långsamt innan så går det väldigt mycket mer långsamt när man läser/skriver baklänges med typ ett block per skivvarv

Vissa tyckte att ska man ändå spegla diskarna i filservern och ha bra backup så kan man ta de billigaste..

Är glad jag ändå tog IronWolf.

Snart kommer väl diskarna med ASMR för bättre försäljning också 🙄

Genom att ha backup på minst 3 olika ställen och regelbundet flytta datan till nya enheter, så kan du ha kvar filerna om 20år.

Jag kör dessutom ett filsystem som har paritet vilket kan ge en indikation på om jag drabbas av bitröta. Vilket hänt mig i flashbaserade sekundärminnen.

För att sammanfatta.

• Det skriks och gnälls allt för mycket på SMR, tekniken blir orättvist behandlad.

• SMR fungerar skitdåligt med NTFS.