SMR hårddisk i NAS, fungerar det för enklare användning?

Hej @Uginuk

Du har uppfattat det rätt, det är vid RAID och mycket skrivning SMR kan ställe till det. Som en ensam disk är inte SMR mindre tillförlitlig än någon annan disk.

Jag har kört RAID5 med Seagates archivediskar sedan första 8TB-diskarna gick att köpa i NAS och generellt så är det inte ett problem mer än att det går långsamt när mdadm-RAID gör resynkning vid utökning av disk eller byte av disk - inte så katastrofalt som man kan se i en del tester (med tex. synology som åtminstone senare versioner använde LVM istället eller i kombination mdadm-RAID vilket kan göra resynkningen mycket värre rent skrivordningsmässigt och till nackdel för SMR-diskar än en plain mdadm-RAID5 som Netgear-NAS:en jag har använder) men tar helt klart en del längre än motsvarade resynk med CMR-diskar. Vid mdadm-RAID resynkning kan man skicka parametrar till kärnan att göra paus på resynkningen och fortsätta igen där det stannade och tex. i ett enkelt script körd i via terminal ge diskarna 10 minuters paus i resynkningen per 1-2 timmar och totalt kan det gå betydligt fortare än att det ligger stumt på hela tiden.

SMR-diskarnas största problem i RAID-sammanhang är just vid utökning av RAID och resynkning och mycket data skall skrivas på kort tid och att det inte ger några pauser tillräckligt långa så att SMR-diskarna kan tömma sin PRM-del då den inte kan göra det parallellt med skrivning/läsning dels för att det slåss om samma RAM på disken men också att enskilda sektorer på PMR-arean kan ta lång tid då 32-64 MB data skall läsas in - modifieras och sedan skrivas tillbaka om det är ensam sektor för segmentet.

Är PMR-arean dessutom stumfull ock disken forcerar sig att börja tömma i alla fall några sektorer i PMR-arena för att kunna köra vidare så kan söktiden för sektorer inom PMR-arena och med skrivning göra att disken inte svarar inom 8 sekunder och då får man verkan med som skedde WD-RED med då okända SMR-diskar och ZFS att diskar kickades ut på löpande band och det blev en för lite för att RAID:en skall fungera och det blev havererad volym av det.

I övrig användning och med BTRFS som filsystem så märker man inte mycket av de nackdelar som förknippas med SMR-diskar vid skrivning - men å andra sidan är BTRFS redan från början väldigt snäll mot SMR-diskar och klarar typ 100 ggr mer småfilsskrivning än tex. NTFS innan det riskerar slå i 'väggen' - NTFS är å andra sidan bland det värsta man kan ha som filsystem på en SMR-disk och olyckligt att det är standardfilsystemet på alla externa USB-snurrdiskar för att vara windows-kompatibel, som alla har SMR-diskar för storlekar 8TB och mindre och drar SMR-tekniken extra mycket i smutsen fast det till stor del beror på väldigt illa hanterad och ej optimerad skrivordning i NTFS i sig själv.

För läsning av filer så är det ingen större skillnad mot CMR-diskar.

Sedan påverkas prestandan med vilken filsystem man använder - Använder man NTFS på snurrdisk så får man skylla sig själv och på SMR-disk snabbt riskera 'väggen' om man tex. kör torrent eller kopierar alla filerna på windows-systemdisken till SMR-disken då det som gömmer sig under windows mappar kan vara hundratusentals småfiler, tomma filer eller hårda länkar i en mogen win-OS filsystem och det kan får en 2.5" 4-5 TB USB-disk (som är SMR idag) att princip stanna av och du tror disken gått sönder och överföringen behöver pausas över en timme, ja kanske flera timmar innan disken är användbar igen - använd tex. total-commanders copy för att kunna pausa överföringen - inte windows egna...

Nu såg jag men ej provat ännu att det finns en implementation av BTRFS för windows skriven från scratch källkodsmässigt och har varit ute ett antal år.

https://github.com/maharmstone/btrfs

jag har inte själv provat, och skulle inte börja med känslig data förrän det bevisat sig själv att vara stabil med hård användning över tid, rycka ur USB-sladd av 'misstag' under full skrivning några dussintals gånger etc. och se att det överlever och hittar tillbaka igen efteråt (om inte, prova med linux med förmodligen bättre recovery av filsystem) - men om man ser hur det fungerar över linux så tål den väldigt mycket mer småskrivningar och i olika ordningar (som torrent) på SMR-diskar än NTFS, typ en faktor hundra gånger bättre än NTFS, - men också ha i minnet, det har mycket att göra hur koden är skriven för windows och skrivstrategierna där vilket inte alls behöver vara samma som i Linux och därmed helt olika upplevelser i prestanda.

- någon indikerat att den är rätt långsam (men det är inte så konstigt och tar många år att finputsa för prestanda och det är detta som gör filsystem så jobbiga att underhålla på källkodsnivå - tusen trix för att öka dess prestanda och lista ut hur resterande OS motarbetare eller hjälper till i flödet)

Kan inte säga om det är bättre eller sämre alternativ till NTFS i den implementationen just nu.