Western Digital släpper världens första hårddisk med 15 TB lagringsutrymme

Eftersom den använder SMR (alias "så långsam att du vill gråta när den måste shingel-skriva") så är den bättre lämpad för backup än vardagsbruk, och ju större backupdisk desto fler backups får man plats med.

99% av belastningen på en backupdisk är ju just skrivningar... en disk som är superdålig på skrivningar är kanske inte riktigt rätt applikation för en SMR-disk. Långsamma skrivningar gör att backupen i slutändan tar för lång tid.

För mig låter det som att detta är mycket mer användbart för en applikation som måste lagra stora mängder data som ofta läses men sällan skrivs. Tänk typ en videoströmningstjänst.

Så sitter man här med endast Seagate HDD i datorn.

Så illa fungerar inte en SMR-disk.

Med Segates Archive-disk skulle säga att de fungerar alldeles utmärkt i de flesta situationerna men det finns lägen i samband med enorm många småfiler och illa passande filsystem som NTFS då det kan bli riktig tjuriga och man måste lämna dessa ifred en tid (ca 30 minuter i regel, görs med Ctrl-z i en rsync-session i linux-consol och efter tiden fortsätter med 'fg <enter>') så att de får städa upp sig internt innan det blir fart på dem igen.

När man 'kör huvudet i väggen' beror också på använda filsystem (_väldigt påverkande!_), typ av fil-storlekar och antal och hur stor totala skrivna backup-potten är.

Är det under 30 GB skrivet i en session så kommer man aldrig se någon stopp oavsett då dess interna scratch-pad är större än så - i de flesta fallen en bra bit över 100-200 GB med massiva mängder småfiler (flera hundratusental) innan det märks av även med för disken så illa hanterande filsystem som NTFS.

På andra filsystem som BTRFS/ext4 så kan det handla om TB med småfiler innan man nåt taket, är det större filer (läs mediafiler) når man aldrig detta utan det skriver så mycket disken orkar hela vägen - är det sekventiellt för större filer så är det uppemot 190 MB/s i skrivning (råhastighet mot själva disken alltså) i början på disken och som de flesta snurrdiskar halva värdet nära slutet av diskens kapacitet - kör man över 1GB-ethernet så kommer disken aldrig att flaska).

SMR går att hantera och ha bra prestanda om man gör det efter dess egna villkor - men drar man mothårs som med användande av NTFS-filsystem så kan det bli grinigt ganska tidigt.

Jag använder ett antal Seagate Archivediskar som just backupmedia med BTRF som filsystem och därmed möjlighet att göra snapshot och därmed versioner/generationer av backup och komprimerande filsystem förutom att nyttja den checksummande funktionen filsystemet har på både data och metadata samt möjlighet att upptäcka korrupta sektorer (ej hänt hittills) - samt metadatat körs dubblerad för redundans och möjlig räddning ifall det blir akut stopp/fel/sladdutryck av någon orsak[1]. Med rsync som filsystems-speglingsprogram och för backupjobbet har dom fungerat alldeles förträffligt.

[1]
Jag är fortfarande bränd av konsekvenserna det blir när 4 första Kbyte av $MFT och $MFT_mirr blir korrupt samtidigt i NTFS-filsystem av en USB/SATA chip i en extern WD-Book USB-disk i samband med avstängning/avmontering från windows enligt konstens alla regler - 3 gånger på 3 olika 3.5" WD-book (2TB) har jag råkat ut för detta, första gången jäkligt smärtsam med seriösa dataförluster, de andra gångerna hade backup på andra diskfabrikat än WD med lärdom av första gången...

Det är ingen större problem att ha dessa archive-diskar även i NAS om det är modesta krav som tex. mediabibilotek, vilket säkert gäller >95% av alla hemma-NAS - skickar man filerna genom 1 GB-Ethernet så är det max 33 MB/s per disk i en 4-disk NAS och disken toppar runt 190 MB/s styck - skulle det gå lite tungt så får man pausa överföringen minst en halvtimme och sedan kan man köra på igen under flera timmar framöver innan nästa paus.

Skall man ha NAS till annat också, köra en massa appar, torrent, databas, docker/VM - nej då är de inte lämpliga diskar då det kommer att börja skriva spritt över diskytan med små skrivningar här och där och det kan bli topplast-perioder då det blir för mycket som inte hinner betas av, scratch-paden blir full på diskarna (dock pratar vi om ~100GB liggande skrivningar på en fyrdisk-NAS) och man får stall och dålig kapacitet - där skall man ha andra diskar med mer predikerbar söktid.

Pengamässigt kan man köpa bra många sådana här diskar innan man nått upp priset på en enda ny LTO-bandare av senaste och näst senaste generationen, och man behöver köpa rätt många bandkassetter också innan man börja spara kostnad med band i jämförelse med att köpa stora arkiv-diskar av SATA-modell.

Och erfarenhetsmässigt så är hårddiskar mer långtidssäkra än bandbackupper - inte i avseende på just lagringmedia - där är nog band överlägset, men problemet är fungerande bandmaskin efter säg 10 år och kanske tusentals kassetters körning - medans en hårddisk är självförpackad och med mycket långlivade gränssnitt. (har buntar med gamla QIC/Travan-kassetter jag inte kan läsa och bandet som driver runt det hela börjat klibba/går av med draghållbarhet som kokt spagetti) - men jag kan fortfarande läsa felfritt hårddiskar från 1984 med innehållet intakt (dock lite bök med datorer innan PC blev vanligt, men det går!)

Även om man stöter på en gammal IDE-disk så kan man med rimlig insats hitta adapter trots att gränssnittet slutat att användas för typ 10 år sedan.

För att cache i hårddiskar inte är samma sak som vad SSD'er använder.

Anta t.ex. att information som startar på en viss plats på disken efterfrågas.
Armen flyttas till rätt spår, men missar precis området där datan startar p.g.a. rotationen.
Då läser den i alla fall in all data på det nästan fulla varvet som behövs för att hitta början igen.
För chansen att resten av datan på varvet även behöver läsas is finns ju.

Så därför ökar HDD cache storleken med densiteten på HD'n.

HDD cachen kan såklart även användas för att snabba upp åtkomst till småfiler, men varför skicka data över ett "långsamt" interface när OS'et redan gör samma jobb mot RAM som det dessutom finns många gånger mer av.

SMR-diskar har inte "dålig skrivprestanda" över lag, utan bara i vissa specifika fall, när man modifierar data som i sin tur orsakar att data i överlappande spår måste skrivas om.

De överlappande spåren är uppdelade i "band", annars skulle man i teorin kunna råka ut för att all data på hela disken behövde skrivas om (spår 0 överlappar spår 1 som överlappar spår 2 o.s.v.). Så det är bara ett litet område som behöver skrivas om, även i värsta fall. Det finns även en icke-SMR yta som fungerar som en slags "cache". Så länge det finns ledigt utrymme på disken finns det algoritmer som kan "peta in" det nya datat utan att andra spår behöver skrivas om.

Så att använda en SMR-disk för t.ex. lagring av media, backuparkiv o.s.v. fungerar alldeles utmärkt, men är disken 99% full och du får för dig att ändra lite i en massa filer här och där på disken lär det bli problem. Därför fungerar de inte heller optimalt i RAID, eftersom det tar orimligt länge att bygga om arrayen.

Normalt spelar det väldigt liten roll för en privatperson hur lång tid det tar att köra en backup, om man nu inte gillar att sitta och stirra på när backupprogrammet jobbar förstås. Själv låter jag min server sköta det jobbet per automatik i bakgrunden, och kör med SMR-diskar vilket funkar perfekt; huvudsaken är att det ryms mycket data (och att det går fort att läsa vid eventuell restore).

Men ja, bäst lämpad är den förstås som arkiv; skriv en gång, läs många.

Snark...

Kolla vid capacity, detta är en volym på 21TB och vad står det där.
Testa ta upp en fil och kolla egenskaper på den så kanske du kan se likheten...

Om du tror detta Cacheminne på SSD används till din data, har du fel.
DRAM används till nästan uteslutande del för diskens meta data, översättningstabeller och liknande.

I en HDD är en LBA adress en specifik sektor. I en SSD är detta översatt till en sektor för SSDn, men detta ändras när ny data skrivs. Genom att lägga dessa tabeller i DRAM så kan man snabba upp skrivning och hantering på helt annan nivå (är inte möjligt att göra några 1TB+ skrivning utan det).

I en HDD används det som ren cache... där diskens 4k prestanda och NCQ algoritm behöver detta för att han en chans till vettigt prestanda. Så en HDD behöver inte så stor cache som SSD måste ha.

"men det är trist att NTFS landar på en hel terabite under kapacitetens mått"

Detta tolkar jag som att du vill påvisa att med NTFS "tappar" man kapacitet vilket _inte_ är fallet.
Om du menade ngt annat så utveckla.