{"id":83582,"date":"2020-06-01T19:42:21","date_gmt":"2020-06-01T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost"},"modified":"2020-06-01T19:42:21","modified_gmt":"2020-06-01T17:42:21","slug":"osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"Grunderna i ZFS: lagringssystem och prestanda","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Grunderna
\n
\nDen h\u00e4r v\u00e5ren har vi redan diskuterat vissa introduktionsteman, som hur du kontrollerar hastigheten p\u00e5 dina diskar<\/a><\/noindex> och vad RAID \u00e4r<\/a><\/noindex>. I den andra lovade vi till och med att forts\u00e4tta studera prestanda f\u00f6r olika fler-disktopologier i ZFS. Detta \u00e4r n\u00e4sta generations filsystem som nu implementeras \u00f6verallt: fr\u00e5n Apple<\/a><\/noindex> till Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nN\u00e5v\u00e4l, idag \u00e4r den mest passande dagen f\u00f6r att bekanta sig med ZFS, nyfikna l\u00e4sare. Bara kom ih\u00e5g att enligt en blygsam uppskattning fr\u00e5n OpenZFS-utvecklaren Matt Arens, \"det \u00e4r verkligen komplicerat\".<\/p>\n

Men innan vi kommer till siffrorna - och de kommer, det lovar jag - f\u00f6r alla alternativ f\u00f6r \u00e5ttadiskkonfigurationer av ZFS, m\u00e5ste vi prata om hur som<\/i> ZFS \u00f6verhuvudtaget lagrar data p\u00e5 disken.<\/p>\n

Zpool, vdev och device<\/h1>\n

\n\"Grunderna
\nDetta diagram f\u00f6r den fullst\u00e4ndiga poolen inkluderar tre st\u00f6djande vdev’ar, en av varje klass, och fyra f\u00f6r RAIDz2<\/i><\/p>\n

\"Grunderna
\nVanligtvis finns det inga sk\u00e4l att skapa en pool av olika typer och storlekar av vdev - men om du vill, finns inget som hindrar dig fr\u00e5n att g\u00f6ra det<\/i><\/p>\n

F\u00f6r att verkligen f\u00f6rst\u00e5 filsystemet ZFS m\u00e5ste man ta en noggrann titt p\u00e5 dess faktiska struktur. F\u00f6r det f\u00f6rsta f\u00f6renar ZFS traditionella niv\u00e5er av volymhantering och filsystem. F\u00f6r det andra anv\u00e4nder det en transaktionell mekanism f\u00f6r kopiering vid skrivning. Dessa egenskaper inneb\u00e4r att systemet \u00e4r strukturellt mycket annorlunda \u00e4n vanliga filsystem och RAID-arrayer. Den f\u00f6rsta upps\u00e4ttningen grundl\u00e4ggande byggstenar f\u00f6r f\u00f6rst\u00e5else: det \u00e4r lagringspoolen (zpool), det virtuella enhet (vdev) och den verkliga enheten (device).<\/p>\n

zpool<\/h3>\n

\nLagringspoolen zpool \u00e4r den \u00f6versta strukturen i ZFS. Varje pool inneh\u00e5ller en eller flera virtuella enheter. I sin tur inneh\u00e5ller var och en av dem en eller flera verkliga enheter (device). Virtuella pooler \u00e4r frist\u00e5ende block. En fysisk dator kan inneh\u00e5lla tv\u00e5 eller flera separata pooler, men varje \u00e4r helt oberoende av de andra. Pooler kan inte dela virtuella enheter.<\/p>\n

Redundansen i ZFS finns p\u00e5 niv\u00e5n av virtuella enheter, snarare \u00e4n p\u00e5 niv\u00e5n av pooler. P\u00e5 poolniv\u00e5 finns det absolut ingen redundans - om n\u00e5gon vdev-lagringsenhet eller special-vdev g\u00e5r f\u00f6rlorad, f\u00f6rloras hela poolen.<\/p>\n

Moderna lagringspooler kan \u00f6verleva f\u00f6rlust av cache eller logg fr\u00e5n det virtuella enheten \u2013 \u00e4ven om de kan f\u00f6rlora en liten m\u00e4ngd orena data om de f\u00f6rlorar vdev-loggen under str\u00f6mavbrott eller systemfel.<\/p>\n

Det finns en vanlig missuppfattning om att \"data stripes\" (strimmor) av ZFS skrivs \u00f6ver hela poolen. Detta \u00e4r fel. Zpool \u00e4r inte helt enkelt en rolig RAID0, det \u00e4r snarare en rolig JBOD<\/a><\/noindex> med en komplex och variabel mekanism f\u00f6r f\u00f6rdelning.<\/p>\n

F\u00f6r det mesta f\u00f6rdelas poster mellan tillg\u00e4ngliga virtuella enheter baserat p\u00e5 det tillg\u00e4ngliga fria utrymmet s\u00e5 att teoretiskt alla kommer att fyllas samtidigt. I senare versioner av ZFS beaktas den aktuella anv\u00e4ndningen (utnyttjandet) av vdev - om en virtuell enhet \u00e4r betydligt mer belastad \u00e4n en annan (till exempel p\u00e5 grund av l\u00e4sningsbelastning) kommer den tillf\u00e4lligt att hoppa \u00f6ver f\u00f6r skrivning, trots att det finns den h\u00f6gsta andelen ledigt utrymme.<\/p>\n

De inbyggda mekanismerna f\u00f6r att best\u00e4mma utnyttjandet i moderna metoder f\u00f6r skrivf\u00f6rdelning i ZFS kan minska latensen och \u00f6ka bandbredden under perioder av ovanligt h\u00f6g belastning - men det \u00e4r inte fritt spelrum<\/i> f\u00f6r oavsiktlig blandning av l\u00e5ngsamma HDD och snabba SSD i en och samma pool. En s\u00e5dan oj\u00e4mlik pool kommer fortfarande att fungera med hastigheten hos den l\u00e5ngsammaste enheten, det vill s\u00e4ga som om den helt best\u00e5r av s\u00e5dana enheter.<\/p>\n

vdev<\/h3>\n

\nVarje lagringspool best\u00e5r av en eller flera virtuella enheter (virtual device, vdev). I sin tur inkluderar varje vdev en eller flera verkliga enheter. De flesta virtuella enheter anv\u00e4nds f\u00f6r enkel datalagring, men det finns flera hj\u00e4lpklasser av vdev, inklusive CACHE, LOG och SPECIAL. Varje typ av vdev kan ha en av fem topologier: enhet (single-device), RAIDz1, RAIDz2, RAIDz3 eller spegel (mirror).<\/p>\n

RAIDz1, RAIDz2 och RAIDz3 \u00e4r speciella varianter av det som gamla kallar RAID med dubbel (diagonal) paritet. 1, 2 och 3 syftar p\u00e5 hur m\u00e5nga paritetsblock som tilldelas f\u00f6r varje dataruta. Ist\u00e4llet f\u00f6r separata diskar f\u00f6r att s\u00e4kerst\u00e4lla paritet, f\u00f6rdelar RAIDz virtuella enheter denna paritet j\u00e4mnt \u00f6ver diskarna. En RAIDz-array kan f\u00f6rlora lika m\u00e5nga diskar som den har paritetsblock; om den f\u00f6rlorar en till, g\u00e5r den s\u00f6nder och drar med sig lagringspoolen.<\/p>\n

I speglade virtuella enheter (mirror vdev) lagras varje block p\u00e5 varje enhet i vdev. \u00c4ven om de vanligaste \u00e4r dubbelspeglar (two-wide) kan det i spegeln finnas ett godtyckligt antal enheter \u2014 i st\u00f6rre installationer anv\u00e4nds ofta tredubbla speglar f\u00f6r att \u00f6ka l\u00e4sprestanda och redundans. En vdev-spegel kan \u00f6verleva vilken fel som helst s\u00e5 l\u00e4nge minst en enhet i vdev forts\u00e4tter att fungera.<\/p>\n

Enskilda vdev \u00e4r i grunden farliga. En s\u00e5dan virtuell enhet \u00f6verlever inte ett enda fel \u2014 och om den anv\u00e4nds som lagring eller speciell vdev, kommer dess fel att f\u00f6rst\u00f6ra hela poolen. V\u00e4rna om detta, var mycket, mycket f\u00f6rsiktig.<\/p>\n

Virtuella enheter CACHE, LOG och SPECIAL kan skapas enligt n\u00e5gon av de ovanst\u00e5ende topologierna \u2014 men kom ih\u00e5g att f\u00f6rlust av den virtuella enheten SPECIAL inneb\u00e4r f\u00f6rlust av poolen, s\u00e5 det rekommenderas starkt att ha en redundant topologi.<\/p>\n

enhet<\/h3>\n

\nDetta \u00e4r troligen den enklaste termen att f\u00f6rst\u00e5 inom ZFS \u2014 det \u00e4r bokstavligen ett blockenhet av godtycklig \u00e5tkomst. Kom ih\u00e5g att virtuella enheter best\u00e5r av separata enheter, och en pool \u00e4r gjord av virtuella enheter.<\/p>\n

Diskar \u2014 magnetiska eller solid state \u2014 \u00e4r de mest vanligt f\u00f6rekommande blockenheter som anv\u00e4nds som byggstenar f\u00f6r vdev. Men vilken enhet som helst med en beskrivning i \/dev fungerar \u2014 s\u00e5 hela h\u00e5rdvaru-RAID-arrayer kan anv\u00e4ndas som separata enheter.<\/p>\n

En enkel r\u00e5fil \u00e4r en av de viktigaste alternativa blockenheterna som kan anv\u00e4ndas f\u00f6r att bygga en vdev. Testpoolar av komprimerade filer<\/a><\/noindex>\u00a0\u00e4r ett mycket bekv\u00e4mt s\u00e4tt att kontrollera poolkommandon och se hur mycket utrymme som \u00e4r tillg\u00e4ngligt i poolen eller det virtuella enheten i den aktuella topologin.<\/p>\n

\"Grunderna
\nDu kan skapa en testpool av sparade filer p\u00e5 bara n\u00e5gra sekunder \u2013 men gl\u00f6m inte att ta bort hela poolen och dess komponenter efter\u00e5t.<\/i> <\/p>\n

Anta att du vill s\u00e4tta upp en server med \u00e5tta diskar och planerar att anv\u00e4nda diskar p\u00e5 10 TB (~9300 GiB) \u2013 men du \u00e4r inte s\u00e4ker p\u00e5 vilken topologi som b\u00e4st matchar dina behov. I exemplet ovan bygger vi en testpool av sparade filer p\u00e5 bara n\u00e5gra sekunder \u2013 och nu vet vi att en RAIDz2 vdev av \u00e5tta diskar p\u00e5 10 TB ger 50 TiB anv\u00e4ndbar kapacitet.<\/p>\n

En annan speciell klass av enheter \u00e4r SPARE (reserv). Hot-swap-enheter, till skillnad fr\u00e5n vanliga enheter, tillh\u00f6r hela poolen och inte en enskild virtuell enhet. Om n\u00e5gon vdev i poolen g\u00e5r s\u00f6nder och reservutrustningen \u00e4r ansluten till poolen och tillg\u00e4nglig, ansluter den automatiskt till den skadade vdev.<\/p>\n

N\u00e4r reservutrustningen ansluts till den skadade vdev b\u00f6rjar den ta emot kopior eller rekonstruktioner av de data som borde finnas p\u00e5 den f\u00f6rlorade enheten. I traditionell RAID kallas detta \u00e5teruppbyggnad (rebuilding), och i ZFS kallas det \"\u00e5terst\u00e4llning av redundans\" (resilvering).<\/p>\n

Det \u00e4r viktigt att notera att reservutrustningen inte permanent ers\u00e4tter de enheter som har slutat fungera. Det \u00e4r bara en tillf\u00e4llig ers\u00e4ttning f\u00f6r att minska den tid under vilken vdev \u00e4r i ett f\u00f6rs\u00e4mrat tillst\u00e5nd. N\u00e4r administrat\u00f6ren har ersatt den trasiga enheten i vdev, sker det en \u00e5terst\u00e4llning av redundans p\u00e5 den permanenta enheten, och SPARE kopplas fr\u00e5n vdev och \u00e5terg\u00e5r till att vara en reserv f\u00f6r hela poolen.<\/p>\n

Datasatser, block och sektorer<\/h1>\n

\nDen n\u00e4sta upps\u00e4ttningen byggstenar som vi beh\u00f6ver f\u00f6rst\u00e5 i v\u00e5r resa genom ZFS handlar mindre om h\u00e5rdvaran och mer om hur sj\u00e4lva data \u00e4r organiserade och lagrade. H\u00e4r hoppar vi \u00f6ver n\u00e5gra niv\u00e5er \u2013 s\u00e5som metaslab \u2013 f\u00f6r att inte \u00f6verbelasta detaljerna, och bibeh\u00e5lla f\u00f6rst\u00e5elsen f\u00f6r den \u00f6vergripande strukturen.<\/p>\n

Datasats (dataset)<\/h3>\n

\n\"Grunderna
\nN\u00e4r vi f\u00f6rst skapar en datasats visar den hela det tillg\u00e4ngliga utrymmet i poolen. Sedan st\u00e4ller vi in en kvot \u2013 och \u00e4ndrar monteringspunkten. Magi!<\/i> <\/p>\n

\"Grunderna
\nZvol \u00e4r mestadels bara en datasats utan sitt filsystemslager, som vi h\u00e4r ers\u00e4tter med ett helt normalt filsystem som ext4.<\/i> <\/p>\n

ZFS-datasettet \u00e4r ungef\u00e4r liknande en standardmonterad filsystem. Precis som ett vanligt filsystem kan det vid f\u00f6rsta anblick verka som \"bara en annan mapp\". Men precis som med vanliga monterade filsystem har varje ZFS-dataset sin egen upps\u00e4ttning grundl\u00e4ggande egenskaper.<\/p>\n

F\u00f6r det f\u00f6rsta kan det finnas en tilldelad kvot f\u00f6r datasetet. Om du st\u00e4ller in zfs set quota=100G poolname\/datasetname<\/code>, kan du inte skriva till den monterade mappen \/poolname\/datasetname<\/code> mer \u00e4n 100 GiB.<\/p>\n

M\u00e4rkte du n\u00e4rvaron \u2013 och fr\u00e5nvaron \u2013 av snedstreck i b\u00f6rjan av varje rad? Varje dataset har sin egen plats b\u00e5de i ZFS-hierarkin och i systemmonteringshierarkin. I ZFS-hierarkin finns det inget ledande snedstreck \u2013 du b\u00f6rjar med poolens namn och g\u00e5r sedan v\u00e4gen fr\u00e5n ett dataset till n\u00e4sta. Till exempel, pool\/parent\/child<\/code> f\u00f6r ett dataset med namnet child<\/code> under den \u00f6verordnade datasetet parent<\/code> i en pool med ett kreativt namn. pool<\/code>.<\/p>\n

Som standard \u00e4r monteringspunkten f\u00f6r datasetet likv\u00e4rdig med dess namn i ZFS-hierarkin, med ett snedstreck i b\u00f6rjan \u2013 poolen med namnet pool<\/code> monteras som \/pool<\/code>, datasetet parent<\/code> monteras i \/pool\/parent<\/code>, och det underordnade datasetet child<\/code> monteras i \/pool\/parent\/child<\/code>. Men den systemmonterade punkten f\u00f6r datasetet kan \u00e4ndras.<\/p>\n

Om vi anger zfs set mountpoint=\/lol pool\/parent\/child<\/code>, d\u00e5 kommer datasetet pool\/parent\/child<\/code> att monteras i systemet som \/lol<\/code>.<\/p>\n

F\u00f6rutom datasets m\u00e5ste vi n\u00e4mna volymer (zvols). En volym \u00e4r ungef\u00e4r liknande ett dataset, f\u00f6rutom att den faktiskt inte har n\u00e5got filsystem \u2013 det \u00e4r bara en blockenhet. Du kan till exempel skapa zvol<\/code> med namnet mypool\/myzvol<\/code>, formattera det med ett ext4-filsystem och sedan montera detta filsystem \u2013 nu har du ett ext4-filsystem, men med st\u00f6d f\u00f6r alla ZFS-s\u00e4kerhetsfunktioner! Det kan verka dumt p\u00e5 en dator, men ger mycket mer mening som backend n\u00e4r du exporterar en iSCSI-enhet.<\/p>\n

Block<\/h3>\n

\n\"Grunderna
\nEn fil presenteras av en eller flera block. Varje block lagras p\u00e5 en virtuell enhet. Blockstorleken \u00e4r vanligtvis lika med parametern recordsize<\/b>, men kan minskas till 2^ashift<\/b>, om den inneh\u00e5ller metadata eller en liten fil.<\/i><\/p>\n

\"Grunderna
\nVi menar verkligen, verkligen<\/b> att vi inte sk\u00e4mtar om den enorma prestandaf\u00f6rlusten om ashift st\u00e4lls in p\u00e5 f\u00f6r l\u00e5gt.<\/i><\/p>\n

I ZFS-pool lagras all data, inklusive metadata, i block. Den maximala blockstorleken f\u00f6r varje datasets definieras i egenskapen recordsize<\/code> (inrecordstorlek). Recordstorleken kan \u00e4ndras, men detta p\u00e5verkar inte storleken eller placeringen av n\u00e5gra block som redan har skrivits till datasetet \u2013 det g\u00e4ller endast f\u00f6r nya block n\u00e4r de skrivs.<\/p>\n

Om inget annat anges \u00e4r den aktuella standardrecordstorleken 128 KiB. Detta \u00e4r en slags kompromiss d\u00e4r prestandan inte kommer att vara perfekt, men inte heller d\u00e5lig i de flesta fall. Recordsize<\/code> kan st\u00e4llas in p\u00e5 vilket v\u00e4rde som helst fr\u00e5n 4K till 1M (med ytterligare inst\u00e4llningar recordsize<\/code> kan st\u00e4llas in \u00e4nnu h\u00f6gre, men det \u00e4r s\u00e4llan en bra id\u00e9).<\/p>\n

Varje block refererar endast till data fr\u00e5n en fil \u2013 du kan inte trycka in tv\u00e5 olika filer i ett block. Varje fil best\u00e5r av ett eller flera block, beroende p\u00e5 storlek. Om filens storlek \u00e4r mindre \u00e4n recordstorleken, kommer den att sparas i ett mindre block \u2013 till exempel kommer ett block med en 2 KiB fil bara att ta en sektor p\u00e5 4 KiB p\u00e5 disken.<\/p>\n

Zvol-voly har ingen egenskap recordsize<\/code>\u00a0\u2013 ist\u00e4llet har de en motsvarande egenskap volblocksize<\/code>.<\/p>\n

Sektorer<\/h3>\n

\nDen sista, mest grundl\u00e4ggande byggstenen \u00e4r sektorn. Detta \u00e4r den minsta fysiska enheten som kan skrivas eller l\u00e4sas fr\u00e5n den grundl\u00e4ggande enheten. Under flera decennier har de flesta diskar anv\u00e4nt sektorer p\u00e5 512 byte. P\u00e5 senare tid har de flesta diskar st\u00e4llts in p\u00e5 sektorer p\u00e5 4 KiB, och i vissa fall \u2013 speciellt SSD \u2013 sektorer p\u00e5 8 KiB eller till och med mer.<\/p>\n

I ZFS-systemet finns det en egenskap som till\u00e5ter manuell inst\u00e4llning av sektorns storlek. Denna egenskap ashift<\/code>. Det \u00e4r ganska f\u00f6rvirrande att ashift \u00e4r en exponent av tv\u00e5. Till exempel, ashift=9<\/code> betyder sektorns storlek 2^9 eller 512 byte.<\/p>\n

ZFS beg\u00e4r detaljerad information om varje blockenhet fr\u00e5n operativsystemet n\u00e4r den l\u00e4ggs till i en ny vdev och st\u00e4ller teoretiskt sett in ashift automatiskt baserat p\u00e5 denna information. Tyv\u00e4rr ljuger m\u00e5nga diskar om sin sektorstorlek f\u00f6r att beh\u00e5lla kompatibilitet med Windows XP (som inte kunde f\u00f6rst\u00e5 diskar med andra sektorstorlekar).<\/p>\n

Detta inneb\u00e4r att en ZFS-administrat\u00f6r starkt rekommenderas att k\u00e4nna till den faktiska sektorstorleken p\u00e5 sina enheter och st\u00e4lla in den manuellt ashift<\/code>. Om ashift \u00e4r inst\u00e4llt f\u00f6r l\u00e5gt \u00f6kar antalet l\u00e4s-\/skrivoperationer astronomiskt. S\u00e5 om man skriver 512-byte \u00absektorer\u00bb till en verklig 4 KiB-sektor m\u00e5ste man f\u00f6rst skriva den f\u00f6rsta \u00absektorn\u00bb, sedan l\u00e4sa 4 KiB-sektorn, \u00e4ndra den med den andra 512-byte \u00absektorn\u00bb, skriva tillbaka den till den nya 4 KiB-sektorn och s\u00e5 vidare f\u00f6r varje skrivning.<\/p>\n

I den verkliga v\u00e4rlden tr\u00e4ffar en s\u00e5dan straff de fasta lagringsenheterna Samsung EVO, f\u00f6r vilka det m\u00e5ste g\u00e4lla ashift=13<\/code>, men dessa SSD:er ljuger om sin sektorstorlek, och d\u00e4rf\u00f6r st\u00e4lls som standard in ashift=9<\/code>. Om inte en erfaren systemadministrat\u00f6r \u00e4ndrar denna parameter kommer denna SSD att fungera l\u00e5ngsammare<\/i> som en vanlig magnetisk HDD.<\/p>\n

F\u00f6r j\u00e4mf\u00f6relse, det finns praktiskt taget inget straff f\u00f6r att ha en f\u00f6r stor storlek ashift<\/code> . Det finns ingen verklig prestandaf\u00f6rlust, och \u00f6kningen av oanv\u00e4nt utrymme \u00e4r o\u00e4ndligt liten (eller noll vid aktiverad komprimering). D\u00e4rf\u00f6r rekommenderar vi starkt \u00e4ven f\u00f6r de diskar som verkligen anv\u00e4nder 512-byte sektorer att st\u00e4lla in ashift=12<\/code> eller till och med ashift=13<\/code>, f\u00f6r att framg\u00e5ngsrikt se in i framtiden.<\/p>\n

Egenskap ashift<\/code> st\u00e4lls in f\u00f6r varje virtuellt enhet vdev, och inte f\u00f6r poolen<\/i>, som m\u00e5nga felaktigt tror \u2013 och \u00e4ndras inte efter att den har st\u00e4llts in. Om du av misstag rubbar ashift<\/code> n\u00e4r du l\u00e4gger till ett nytt vdev i poolen, har du permanent f\u00f6rorenat denna pool med en enhet med l\u00e5g prestanda, och det finns vanligtvis inget annat s\u00e4tt \u00e4n att f\u00f6rst\u00f6ra poolen och b\u00f6rja om fr\u00e5n b\u00f6rjan. \u00c4ven borttagning av vdev r\u00e4ddar inte fr\u00e5n en felaktig inst\u00e4llning. ashift<\/code>!<\/p>\n

Skrivningskopieringsmekanism<\/h3>\n

\n\"Grunderna
\nOm ett vanligt filsystem beh\u00f6ver skriva om data \u2013 \u00e4ndrar den varje block d\u00e4r det st\u00e5r.<\/i><\/p>\n

\"Grunderna
\nFilssystemet med skrivkopiering skriver en ny version av blocket och l\u00e5ser sedan upp den gamla versionen.<\/i><\/p>\n

\"Grunderna
\nI abstrakt bem\u00e4rkelse, om vi ignorerar den faktiska fysiska placeringen av blocken, f\u00f6renklas v\u00e5r \"datakomets\" till ett \"datmask\", som r\u00f6r sig fr\u00e5n v\u00e4nster till h\u00f6ger \u00f6ver kartan av tillg\u00e4ngligt utrymme.<\/i><\/p>\n

\"Grunderna
\nNu kan vi f\u00e5 en bra uppfattning om hur skrivkopieringssnapshot fungerar \u2013 varje block kan tillh\u00f6ra flera snapshots och kommer att sparas s\u00e5 l\u00e4nge alla relaterade snapshots inte har raderats.<\/i><\/p>\n

Skrivkopieringsmekanismen (Copy on Write, CoW) \u00e4r den grundl\u00e4ggande basen f\u00f6r vad som g\u00f6r ZFS till ett s\u00e5 fantastiskt system. Huvudkonceptet \u00e4r enkelt \u2013 om du ber ett traditionellt filsystem att \u00e4ndra en fil, g\u00f6r den precis vad du beg\u00e4rde. Om du ber ett skrivkopierande filsystem att g\u00f6ra samma sak, s\u00e4ger det \"okej\" \u2013 men ljuger f\u00f6r dig.<\/p>\n

Ist\u00e4llet skriver det skrivkopierande filsystemet en ny version av det f\u00f6r\u00e4ndrade blocket och uppdaterar sedan filens metadata f\u00f6r att bryta kopplingen med det gamla blocket och koppla det till det nya block som just har skrivits.<\/p>\n

Kopplingen av det gamla blocket och bindningen av det nya sker i en operation, s\u00e5 denna kan inte avbrytas \u2013 om du st\u00e4nger av str\u00f6mmen efter att det har skett, har du en ny version av filen, och om du st\u00e4nger av str\u00f6mmen tidigare, har du den gamla versionen. I vilket fall som helst kommer det inte att uppst\u00e5 n\u00e5gra konflikter i filsystemet.<\/p>\n

Skrivkopiering i ZFS sker inte bara p\u00e5 filsystemniv\u00e5 utan ocks\u00e5 p\u00e5 diskhanteringsniv\u00e5. Detta inneb\u00e4r att ZFS inte p\u00e5verkas av skrivluckor (RAID-h\u00e5l<\/a><\/noindex>) \u2013 ett fenomen d\u00e4r bandet bara har skrivits delvis innan systemet kraschar, med skador p\u00e5 arrayen efter omstart. H\u00e4r skrivs bandet atom\u00e4rt, vdev \u00e4r alltid konsekvent, och Bob \u00e4r din farbror.<\/a><\/noindex>.<\/p>\n

ZIL: ZFS avsiktslogg.<\/h3>\n

\n\"Grunderna
\nZFS-systemet hanterar synkrona skrivningar p\u00e5 ett speciellt s\u00e4tt \u2013 det sparar dem tempor\u00e4rt men omedelbart i ZIL, innan de senare skrivs permanent tillsammans med asynkrona skrivningar.<\/i><\/p>\n

\"Grunderna
\nVanligtvis l\u00e4ses inte data som skrivs till ZIL n\u00e5gonsin igen. Men det \u00e4r m\u00f6jligt efter ett systemfel.<\/i><\/p>\n

\"Grunderna
\nSLOG, eller sekund\u00e4r LOG-enhet, \u00e4r helt enkelt en speciell - och helst v\u00e4ldigt snabb - vdev d\u00e4r ZIL kan lagras separat fr\u00e5n det prim\u00e4ra lagringsutrymmet.<\/i><\/p>\n

\"Grunderna
\nEfter ett fel \u00e5terst\u00e4lls alla smutsiga data i ZIL - i det h\u00e4r fallet ligger ZIL p\u00e5 SLOG, s\u00e5 de \u00e5terst\u00e4lls d\u00e4rifr\u00e5n.<\/i><\/p>\n

Det finns tv\u00e5 huvudkategorier av skrivoperationer - synkrona (sync) och asynkrona (async). F\u00f6r de flesta arbetsbelastningar \u00e4r den \u00f6verv\u00e4ldigande majoriteten av skrivoperationer asynkrona - filsystemet till\u00e5ter att de aggregeras och skickas i paket, vilket minskar fragmenteringen och avsev\u00e4rt \u00f6kar bandbredden.<\/p>\n

Synkrona skrivningar \u00e4r en helt annan sak. N\u00e4r en applikation beg\u00e4r en synkron skrivning, s\u00e4ger den till filsystemet: \"Du beh\u00f6ver spara det h\u00e4r i icke-flyktigt minne, just nu.<\/i>och under tiden kan jag inte g\u00f6ra n\u00e5got mer.\" D\u00e4rf\u00f6r m\u00e5ste synkrona skrivningar omedelbart sparas p\u00e5 disken - och om det \u00f6kar fragmenteringen eller minskar bandbredden, d\u00e5 f\u00e5r det vara s\u00e5.<\/p>\n

ZFS hanterar synkrona skrivningar annorlunda \u00e4n vanliga filsystem - ist\u00e4llet f\u00f6r att omedelbart skriva dem till det vanliga lagringsutrymmet, sparar ZFS dem i ett speciellt lagringsomr\u00e5de som kallas ZFS Intent Log, eller ZIL. Kniffen \u00e4r att dessa skrivningar \u00e4ven<\/i> f\u00f6rblir i minnet, samtidigt som de aggregeras med vanliga asynkrona skrivf\u00f6rfr\u00e5gningar, f\u00f6r att senare skrivas till lagringsutrymmet som helt normala TXG (transaktionsgrupper, Transaction Groups).<\/p>\n

Under normal drift skrivs ZIL till och l\u00e4ses aldrig mer. N\u00e4r skrivningarna fr\u00e5n ZIL efter n\u00e5gra \u00f6gonblick sparas i det prim\u00e4ra lagringsutrymmet i vanliga TXG fr\u00e5n RAM, kopplas de bort fr\u00e5n ZIL. Det \u00e4r endast d\u00e5 n\u00e5got l\u00e4ses fr\u00e5n ZIL - vid import av poolen.<\/p>\n

Om det intr\u00e4ffar ett ZFS-fel - en krasch av operativsystemet eller str\u00f6mavbrott - n\u00e4r det finns data i ZIL, kommer dessa data att l\u00e4sas under n\u00e4sta import av poolen (t.ex. vid omstart av den avbrutna systemet). Allt som finns i ZIL kommer att l\u00e4sas, aggregeras i TXG-grupper, sparas i det prim\u00e4ra lagringsutrymmet och d\u00e4refter kopplas loss fr\u00e5n ZIL under importprocessen.<\/p>\n

En av hj\u00e4lpklasserna i vdev kallas LOG eller SLOG, en sekund\u00e4r enhet LOG. Dess enda uppgift \u00e4r att tillhandah\u00e5lla poolen med en separat och, helst, mycket snabbare enhet med h\u00f6g skrivbest\u00e4ndighet f\u00f6r lagring av ZIL, ist\u00e4llet f\u00f6r att lagra ZIL p\u00e5 huvudlagringsvdev. ZIL beter sig likadant oavsett lagringsplats, men om vdev med LOG har mycket h\u00f6g skrivprestanda kommer synkrona skrivningar att ske snabbare.<\/p>\n

Att l\u00e4gga till vdev med LOG i poolen p\u00e5verkar inte kan inte<\/b> prestationsf\u00f6rb\u00e4ttringen av asynkrona skrivningar \u2013 \u00e4ven om du tvingar fram alla skrivningar till ZIL med zfs set sync=always<\/code>, kommer de fortfarande att vara bundna till huvudlagringen i TXG p\u00e5 samma s\u00e4tt och i samma takt som utan logg. Den enda direkta prestandaf\u00f6rb\u00e4ttringen \u00e4r latensen av synkrona skrivningar (eftersom en h\u00f6gre hastighet f\u00f6r loggen p\u00e5skyndar utf\u00f6randet av operationer. sync<\/code>).<\/p>\n

Men i en milj\u00f6 som redan kr\u00e4ver m\u00e5nga synkrona skrivningar kan vdev LOG indirekt p\u00e5skynda asynkrona skrivningar och okashad l\u00e4sning. Att avlastar ZIL-skrivningar till en separat vdev LOG inneb\u00e4r mindre konkurrens om IOPS i den prim\u00e4ra lagringen, vilket p\u00e5 vissa s\u00e4tt \u00f6kar prestandan f\u00f6r alla l\u00e4s- och skrivoperationer.<\/p>\n

Snapshots<\/h3>\n

\nSkriv-kopieringsmekanismen \u00e4r \u00e4ven en n\u00f6dv\u00e4ndig grund f\u00f6r atom\u00e4ra momentana bilder i ZFS och inkrementell asynkron replikering. I ett aktivt filsystem finns det ett tr\u00e4d av pekare som markerar alla skrivningar med aktuella data \u2013 n\u00e4r du g\u00f6r en snapshot skapar du helt enkelt en kopia av detta pekartr\u00e4d.<\/p>\n

N\u00e4r en skrivning \u00f6verskrivs i det aktiva filsystemet, skriver ZFS f\u00f6rst den nya versionen av blocket till oanv\u00e4ndbart utrymme. D\u00e4refter kopplar den bort den gamla versionen av blocket fr\u00e5n det aktuella filsystemet. Men om en snapshot h\u00e4nvisar till det gamla blocket f\u00f6rblir det of\u00f6r\u00e4ndrat. Det gamla blocket kommer faktiskt inte att \u00e5terst\u00e4llas som ledigt utrymme f\u00f6rr\u00e4n alla snapshots som h\u00e4nvisar till det blocket har raderats!<\/p>\n

Replikation<\/h3>\n

\n\"Grunderna
\nMitt Steam-bibliotek \u00e5r 2015 tog 158 GiB och inkluderade 126 927 filer. Detta \u00e4r ganska n\u00e4ra den optimala situationen f\u00f6r rsync \u2013 ZFS-replikering \u00f6ver n\u00e4tverket var \"bara\" 750% snabbare.<\/i><\/p>\n

\"Grunderna
\nI samma n\u00e4tverk \u00e4r replikeringen av en 40-gigabyte avbild av en virtuell Windows 7-maskin en helt annan historia. ZFS-replikeringen sker 289 g\u00e5nger snabbare \u00e4n rsync \u2013 eller 'bara' 161 g\u00e5nger snabbare om du \u00e4r tillr\u00e4ckligt kunnig f\u00f6r att anropa rsync med alternativet —inplace.<\/i><\/p>\n

\"Grunderna
\nN\u00e4r avbildningen av den virtuella maskinen skalas, skalas rsync-problemen tillsammans med den. Storleken 1,9 TiB \u00e4r inte s\u00e5 stor f\u00f6r en modern virtuell maskin \u2013 men den \u00e4r tillr\u00e4ckligt stor f\u00f6r att ZFS-replikeringen ska vara 1148 g\u00e5nger snabbare \u00e4n rsync, \u00e4ven med rsync-argumentet —inplace.<\/i><\/p>\n

S\u00e5 snart du f\u00f6rst\u00e5r hur snapshots fungerar, blir det inte sv\u00e5rt att f\u00e5nga essensen av replikering. Eftersom en snapshot helt enkelt \u00e4r ett tr\u00e4d av pekare till poster, inneb\u00e4r det att om vi g\u00f6r zfs send<\/code> en snapshot, s\u00e5 skickar vi b\u00e5de detta tr\u00e4d och alla relaterade poster. N\u00e4r vi \u00f6verf\u00f6r detta zfs send<\/code> p\u00e5 zfs receive<\/code> till det destinationselement, skriver det b\u00e5de det faktiska blockinneh\u00e5llet och tr\u00e4det av pekare som h\u00e4nvisar till blocken, i m\u00e5l datasets.<\/p>\n

Det blir \u00e4nnu mer intressant p\u00e5 den andra zfs send<\/code>. Nu har vi tv\u00e5 system d\u00e4r var och en inneh\u00e5ller poolname\/datasetname@1<\/code>, och du tar en ny snapshot poolname\/datasetname@2.<\/code>D\u00e4rf\u00f6r har du i k\u00e4llpoolen datasetname@1<\/code> och datasetname@2<\/code>, men i m\u00e5lpoolen har vi tills vidare bara den f\u00f6rsta snapshoten. datasetname@1<\/code>.<\/p>\n

Eftersom vi har en gemensam snapshot mellan k\u00e4llan och m\u00e5let, kan vi g\u00f6ra datasetname@1<\/code>en inkrementell \u00f6van dem. N\u00e4r vi s\u00e4ger till systemet<\/i> zfs send<\/code> zfs send -i poolname\/datasetname@1 poolname\/datasetname@2 , j\u00e4mf\u00f6r det de tv\u00e5 pekartr\u00e4den. Alla pekare som endast existerar i<\/code>, pekar uppenbarligen p\u00e5 nya block \u2013 d\u00e4rf\u00f6r beh\u00f6ver vi inneh\u00e5llet i dessa block. @2<\/code>I det fj\u00e4rrsystemet \u00e4r hanteringen av den inkrementella<\/p>\n

lika enkel. F\u00f6rst skriver vi alla nya poster som ing\u00e5r i str\u00f6mmen send<\/code> , och sedan l\u00e4gger vi till pekarna till dessa block. Voil\u00e0, vi har send<\/code>i det nya systemet! @2<\/code> Asynkron inkrementell replikation av ZFS \u00e4r en enorm f\u00f6rb\u00e4ttring j\u00e4mf\u00f6rt med tidigare metoder som inte bygger p\u00e5 snapshots, som rsync. I b\u00e5da fallen \u00f6verf\u00f6rs endast \u00e4ndrade data \u2013 men rsync m\u00e5ste f\u00f6rst<\/p>\n

fr\u00e5n disken alla data p\u00e5 b\u00e5da sidor f\u00f6r att kontrollera summan och j\u00e4mf\u00f6ra den. Till skillnad fr\u00e5n detta l\u00e4ser ZFS-replikering ingenting utom pekartavlor \u2013 och alla block som inte finns representerade i den gemensamma snapshoten. l\u00e4sa<\/i> fr\u00e5n disken all data fr\u00e5n b\u00e5da sidor, f\u00f6r att kontrollera summan och j\u00e4mf\u00f6ra den. Till skillnad fr\u00e5n detta l\u00e4ser ZFS-replikering inget annat \u00e4n pekartr\u00e4d \u2013 och alla block som inte finns i den gemensamma \u00f6gonblicksbilden.<\/p>\n

Inbyggd komprimering<\/h3>\n

\nSkrivprocessens kopieringsmekanism f\u00f6renklar ocks\u00e5 systemet med inbyggd komprimering. I ett traditionellt filsystem \u00e4r komprimering problematiskt \u2013 b\u00e5de den gamla versionen och den nya versionen av \u00e4ndrade data finns i samma utrymme.<\/p>\n

Om vi ser p\u00e5 ett datastycke i mitten av en fil som b\u00f6rjar sitt liv som en megabyte av nollor fr\u00e5n 0x00000000 och s\u00e5 vidare \u2013 kan det enkelt komprimeras till en sektor p\u00e5 disken. Men vad h\u00e4nder om vi ers\u00e4tter denna megabyte av nollor med en megabyte av ocompressibla data, som JPEG eller pseudorandom brus? Pl\u00f6tsligt kommer denna megabyte av data att beh\u00f6va inte en, utan 256 sektorer p\u00e5 4 KiB, medan bara en sektor \u00e4r reserverad p\u00e5 disken.<\/p>\n

ZFS har inget s\u00e5dant problem, eftersom de \u00e4ndrade posterna alltid skrivs till oanv\u00e4nt utrymme \u2013 den ursprungliga blocket tar bara en sektor p\u00e5 4 KiB, medan den nya posten kommer att ta 256, men det \u00e4r inget problem \u2013 det nyligen \u00e4ndrade stycket fr\u00e5n \"mitten\" av filen skulle skrivas till oanv\u00e4nt utrymme oavsett om dess storlek f\u00f6r\u00e4ndrades eller inte, s\u00e5 det \u00e4r en helt normal situation f\u00f6r ZFS.<\/p>\n

Inbyggd komprimering i ZFS \u00e4r avst\u00e4ngd som standard, och systemet erbjuder anslutbara algoritmer \u2013 f\u00f6r n\u00e4rvarande LZ4, gzip (1-9), LZJB och ZLE.<\/p>\n

Om filen \u00e4r tillr\u00e4ckligt stor och kr\u00e4ver flera block, d\u00e5 kommer alla poster med denna fil att ha storlek recordsize<\/code>\u00a0\u2013 inklusive den sista posten, vars huvudsakliga del kan visa sig vara ouppnyttjat utrymme<\/a><\/noindex>.<\/p>\n