ZFS har uppenbara begränsningar som alla borde känna till.

Som beh påpekade, är det någon som testat att checksumma datat så fort det lästs in till RAM med debug flaggan som ZFS arkitekten Matt Ahrens pratar om? Det finns folk som hittat på att trasigt icke ECC ram förstör din ZFS pool, vilket inte stämmer. Problemet är att ZFS inte checksummar datat i RAM, men det går tydligen att göra enligt ZFS skaparen Matt. Man kan visst checksumma datat även i RAM!
http://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=26...

Grejen är att man från ett datavetenskapligt perspektiv bryter en hel del av den separationen som måste finnas mellan de olika lagren i ZFS när man försöker implementera möjligheten att plocka bort en disk (samma som att lägga till en). Detta kallas block pointer rewrite och problemet ligger i att man måste komma i håg alla platser som man har flyttat från disk A till disk B för att man ska kunna frigöra disk A och få en annan redundansnivå (ta bort en disk eller lägga till en disk). Ett annat problem är hur man gör detta på ett säkert sätt och inte råkar förstöra disken om strömmen går mitt under processen.

SMR kräver att filsystemen tar hänsyn till de nya begränsningarna hos diskarna, precis som att SSDs kräver TRIM på filsystemnivå så kräver SMR något liknande för god prestanda. Idag så kan SMR endast användas för arkivlagring eftersom man använder 256 MB stora block på disken. Det kommer att ta lång tid innan man kan köra ZFS på en sådan disk utan stora problem med prestandan.

3 x 4TB RED diskar i RAIDZ1 springer cirklar runt 2 x 8TB SMR Archive i mirror. Om en av dina diskar faller så kommer det att ta flera dagar (4-5) att bygga upp ditt mirror igen (om du inte läser något annat från disken). Jag funderar på att skaffa några SMR diskar, men det skulle endast vara för enkel NTFS arkivering. Inget annat. Absolut inte RAID eller ZFS.

PS. försök att inte särskriv så mycket, det blir mycket svårt att läsa.

Jag tolkar det såhär: Minnesfel kan förstöra en ZFS-pool om man har riktig otur. Minnesfel kan även förstöra andra filsystem, men med andra filsystem har man ibland möjlighet att rädda data men det är omöjligt att veta om dessa data är felfria eller inte (som att läsa ut filer från ett formaterat minneskort, vissa kanske funkar andra är bara brus). Har man defekta minnen så hjälper Ahrens flagga föga, men om man får en plötslig bitflip medan data ligger i RAM-cache innan det skickas ut till klient så kan den rädda dig. Att förlita sig på det ett återskapningsprogram kan skrapa upp från diskarna är en falsk trygghet även om det är bättre än ingenting.

Det är var det som föranla frågan.

ZFS on SMR Drives
http://storageconference.us/2014/Presentations/Novak.pdf

@HåkaN Teknik: Det är sant, men jag tror inte att Nexenta själva klarar att fixa detta. Det är otroligt mycket som måste ändras och testas innan en ZFS för SMR diskar är en realtitet se (lyssna på kommentarerna) denna föreläsningen från OpenZFS European Conference 2015 https://www.youtube.com/watch?v=a2lnMxMUxyc

PS: Ljudet är mycket lågt, men om man pastar in URLen direkt i VLC (Media -> Open Network Stream) och aktiverar kompressorn (Tools -> Effects and filters -> Compressor -> PMS / peak 0.6 Attack 170 ms Threshold -17 dB Ratio 7:1 Knee Radius 2.5 dB Makeup Gain 16 dB så låter det lite bättre.

@MichaelJackson: Jag menar en ZFS-pool med SMR diskar

Ett par idéer för ZFS aktiv lagring på SMR diskar innan SMR prestanda problemen är lösta.

ZFS on SMR Drives är långsamt och kommer vara det tills hantering SMR blir bättre fungerande även om det finns minst ett företag som säger sig ha löst prestanda problemet.
Men SMR kommer en förväntad ökning från 25% till 50% så det har framtiden för sig men tills prestanda frågan fungera bättre hålla sig till standar diskar om det inte är för arkivering.
Så att använda 8TB Seagate Archive 5900rpm 128MB (SMR) som band hålla upp data säkerheten genom att köra som spegel och ha rockader i brandskåpet som Classic band hantering, för fullständiga backupp.

Att hantera när det är för stort att ha alt på en plats köra komplett sett i SMR i back upp komplett Ultrastar HE8 HUH728080ALE604 8TB och 8TB Seagate Archive 5900rpm 128MB (SMR) som kostar en tredjedel så mycket som inte har några läsningar utan bar tar i mot, ha pcie SSDs och sata SSDs i back upp enheten.
Ha en komplett en ide för att börja använda ZFS för SMR innan prestanda problemen är lösta när de är lösta så ökar prestandan men det här är konsument diskar så ha till lagring inte en aktiv server.

@HåkaN Teknik: Ja, det är helt sant. Frågan är om man kommer att kunna dra nytta av dessa typer av "host managed" lagringssystem med dagens SMR diskar (genom firmware update?). Antagligen inte.

Jag har själv en Seagate Archive 8TB som jag kör som singel ZFS enhet och den presterar i topp för det ändamålet jag kör den till, att göra en backup av hela min brukspool med snapshots och bookmarks.

in @  179 MiB/s, out @  179 MiB/s,  173 GiB total, buffer 100% full
in @  164 MiB/s, out @  164 MiB/s,  448 GiB total, buffer 100% full

Det fungerar så länge som man skriver sekventiellt och asynkront, vilket man gör när man utför den initiala backupen. Men eftersom senare backuper är inkrementella så blir det så lite att skriva att det inte borde vara något problem för mig heller.

Den räcker gott och väl som en offline kopia eller online för endast läsningar. Men iSCSI, nfs eller VMs skulle jag inte köra på den.