Udaberri honetan sarrerako gai batzuk landu ditugu jada, adibidez, ΠΈ . Horietako bigarrenean, ZFSko hainbat disko-topologiaren errendimendua aztertzen jarraituko genuela ere agindu genuen. Hau da orain nonahi ezartzen ari den hurrengo belaunaldiko fitxategi-sistema: from to .
Bada, gaurkoa da ZFS, irakurle jakintsuak ezagutzeko egunik onena. Jakin ezazu Matt Ahrens OpenZFS garatzailearen iritzi apalean "oso zaila dela".
Baina zortzi diskoko ZFS konfiguraziorako aukera guztietarako zenbakietara iritsi baino lehen -eta hala egingo dute, agintzen dut-, hitz egin behar dugu. gisa Oro har, ZFS-k datuak diskoan gordetzen ditu.
Zpool, vdev eta gailua
Igerileku osoko diagrama honek hiru vdev laguntzaile ditu, klase bakoitzeko bat eta RAIDz2rako lau
Normalean ez dago arrazoirik bat ez datozen vdev motak eta tamainak sortzeko, baina ez dago ezerk hori egitea eragozten nahi baduzu.
ZFS fitxategi-sistema benetan ulertzeko, bere benetako egiturari arretaz begiratu behar diozu. Lehenik eta behin, ZFS-k bolumenaren eta fitxategi sistemaren kudeaketaren maila tradizionalak bateratzen ditu. Bigarrenik, kopia-idazketa-mekanismo transakzionala erabiltzen du. Ezaugarri hauek esan nahi dute sistema egituraz oso desberdina dela ohiko fitxategi-sistemetatik eta RAID arrayetatik. Ulertu beharreko oinarrizko eraikuntza-blokeen lehen multzoa biltegiratze-igerilekua (zpool), gailu birtuala (vdev) eta gailu erreala (gailua) dira.
zpool
Zpool biltegiratze igerilekua ZFS egiturarik gorenena da. Igerileku bakoitzak gailu birtual bat edo gehiago ditu. Aldi berean, horietako bakoitzak benetako gailu (gailu) bat edo gehiago ditu. Igerileku birtualak bloke autonomoak dira. Ordenagailu fisiko batek bi igerileku bereizi edo gehiago izan ditzake, baina bakoitza besteetatik guztiz independentea da. Igerilekuek ezin dituzte gailu birtualak partekatu.
ZFS-ren erredundantzia gailu birtualean dago, ez igerileku mailan. Igerileku mailan ez dago guztiz erredundantziarik - unitateko vdev edo vdev bereziren bat galtzen bada, igerileku osoa galtzen da harekin batera.
Biltegiratze-igerileku modernoek cache baten edo gailu birtualaren erregistroaren galeraren ondorioz iraun dezakete - datu zikin kopuru txiki bat gal dezaketen arren, energia etenaldi batean edo sistemaren hutsegite batean vdev erregistroa galtzen badute.
Ohiko uste oker bat dago ZFS "datuen marra" igerileku osoan idatzita dagoela. Hau ez da egia. Zpool ez da batere dibertigarria RAID0, nahiko dibertigarria da banaketa aldakorreko mekanismo konplexu batekin.
Gehienetan, sarrerak eskuragarri dauden gailu birtualen artean banatzen dira eskuragarri dagoen espazio librearen arabera, beraz, teorian denak aldi berean beteko dira. ZFSren geroagoko bertsioetan, uneko vdev erabilera (erabilera) hartzen da kontuan; gailu birtual bat beste bat baino nabarmen okupatuta badago (adibidez, irakurketa karga dela eta), aldi baterako saltatu egingo da idazteko, doako altuena izan arren. espazio-erlazioa.
ZFS idazketa-esleipen-metodo modernoetan integratutako erabilera detektatzeko mekanismoak latentzia murrizten du eta errendimendua handitu dezake ohiz kanpoko karga handiko aldietan, baina ez du. karta zuria HDD motelak eta SSD azkarrak igerileku batean nahi gabe nahasteaz. Halako igerileku desberdintasun batek gailu motelenaren abiaduran funtzionatuko du oraindik, hau da, gailuz guztiz osatuta egongo balitz bezala.
vdev
Biltegiratze multzo bakoitzak gailu birtual batek edo gehiagok osatzen dute (gailu birtuala, vdev). Aldi berean, vdev bakoitzak benetako gailu bat edo gehiago ditu. Gailu birtual gehienak datuak biltegiratzeko erabiltzen dira, baina hainbat vdev laguntzaile klase daude, besteak beste, CACHE, LOG eta SPECIAL. Vdev mota horietako bakoitzak bost topologia hauetako bat izan dezake: gailu bakarra (gailu bakarra), RAIDz1, RAIDz2, RAIDz3 edo ispilua (ispilua).
RAIDz1, RAIDz2 eta RAIDz3 antzinakoek parekidetasun bikoitz (diagonal) RAID deituko luketenaren barietate bereziak dira. 1, 2 eta 3-ek datu-banda bakoitzerako zenbat parekotasun-bloke esleitzen diren adierazten dute. Parekidetasunerako disko bereiziak izan beharrean, RAIDz gailu birtualek parekotasun hori erdi berdinean banatzen dute diskoetan. RAIDz array batek parekotasun bloke dituen adina disko gal ditzake; beste bat galtzen badu, huts egingo du eta biltegiratze igerilekua berekin eramango du.
Ispiluzko gailu birtualetan (mirror vdev), bloke bakoitza vdev-ko gailu bakoitzean gordetzen da. Bi zabaleko ispiluak ohikoenak diren arren, edozein gailu kopuru arbitrarioa egon daiteke ispilu batean - hirukoiztuak sarritan erabiltzen dira instalazio handietan irakurketa-errendimendua hobetzeko eta akatsen tolerantzia lortzeko. Vdev ispilu batek edozein hutsegite iraun dezake, vdev-ko gailu batek gutxienez funtzionatzen jarraitzen duen bitartean.
Vdev bakarrak berez arriskutsuak dira. Gailu birtual horrek ez du akats bakar bat bizirik iraungo, eta biltegiratze edo vdev berezi gisa erabiltzen bada, bere hutsegiteek igerileku osoa suntsituko dute. Oso-oso kontuz ibili hemen.
CACHE, LOG eta VA BEREZIAk goiko topologiaren bat erabiliz sor daitezke, baina gogoratu VA BEREZIA galtzeak igerilekua galtzea dakarrela, beraz, oso gomendagarria da topologia erredundantea.
gailu
Hau da ziurrenik ZFS-n ulertzeko terminorik errazena - literalki blokeatu ausazko sarbiderako gailu bat da. Gogoratu gailu birtualak gailu indibidualez osatuta daudela, eta igerilekua, berriz, gailu birtualez osatuta dagoela.
Diskoak - magnetikoak edo egoera solidoa - vdev-en eraikuntza-bloke gisa erabiltzen diren bloke-gailu ohikoenak dira. Hala ere, /dev-en deskribatzailea duen edozein gailu balioko du, beraz, hardware RAID array osoa gailu bereizi gisa erabil daiteke.
Fitxategi gordina sinple bat vdev bat eraiki daitekeen bloke alternatiboko gailu garrantzitsuenetako bat da. Proba igerilekuak igerilekuko komandoak egiaztatzeko eta topologia jakin bateko igerileku edo gailu birtual batean zenbat leku dagoen ikusteko modu oso erabilgarria da.
Fitxategi urrietatik proba-talde bat sor dezakezu segundo gutxitan, baina ez ahaztu igerileku osoa eta bere osagaiak ezabatzea ondoren.
Demagun zerbitzari bat zortzi diskotan jarri nahi duzula eta 10 TBko diskoak (~9300 GiB) erabiltzeko asmoa duzula, baina ez zaude ziur zein topologia egokitzen den zure beharretara. Goiko adibidean, segundotan fitxategi eskasetatik proba-bilduma bat eraikitzen dugu, eta orain badakigu 2 TBko zortzi diskoko RAIDz10 vdev batek 50 TiB-ko ahalmen erabilgarria eskaintzen duela.
Beste gailu klase berezi bat SPARE (ordezko) da. Hot-swap gailuak, ohiko gailuak ez bezala, igerileku osoarenak dira, eta ez gailu birtual bakar batenak. Igerilekuko vdev batek huts egiten badu eta ordezko gailu bat igerilekura konektatuta eta erabilgarri badago, orduan automatikoki sartuko da kaltetutako vdevra.
Kaltetutako vdevra konektatu ondoren, ordezko gailua falta den gailuan egon beharko luketen datuen kopiak edo berreraikuntzak jasotzen hasten da. RAID tradizionalean berreraikitzea deitzen zaio, ZFSn berriz zilarreztatzea.
Garrantzitsua da kontutan izan ordezko gailuek ez dituztela betirako ordezkatzen huts egin duten gailuak. Hau aldi baterako ordezkapena baino ez da vdev degradatzen den denbora murrizteko. Administratzaileak huts egin duen vdev-a ordezkatu ondoren, erredundantzia berrezartzen da gailu iraunkor horretan, eta SPARE vdev-tik deskonektatu eta igerileku osoaren ordezko gisa lanera itzultzen da.
Datu multzoak, blokeak eta sektoreak
Gure ZFS bidaian ulertzeko hurrengo bloke-multzoa hardwareari buruzkoa da gutxiago eta datuak bera nola antolatu eta gordetzen diren. Maila batzuk saltatzen ari gara hemen, adibidez, metalauza, xehetasunak ez nahasteko egitura orokorraren ulermena mantenduz.
Datu multzoa (datu multzoa)
Datu-multzo bat lehen aldiz sortzen dugunean, eskuragarri dagoen igerilekuko espazio guztia erakusten du. Ondoren, kuota ezarri dugu eta muntatze-puntua aldatzen dugu. Magia!
Zvol, gehienetan, fitxategi-sistemaren geruza kendutako datu-multzo bat besterik ez da, hemen ordezkatzen ari garen ext4 fitxategi-sistema guztiz normal batekin.
ZFS datu-multzo bat muntatutako fitxategi-sistema estandar baten berdina da gutxi gorabehera. Fitxategi sistema arrunt bat bezala, lehen begiratuan "beste karpeta bat besterik ez" dirudi. Baina munta daitezkeen fitxategi-sistema arruntek bezala, ZFS datu-multzo bakoitzak bere oinarrizko propietateen multzoa du.
Lehenik eta behin, datu multzo batek esleitutako kuota izan dezake. Ezarri bada zfs set quota=100G poolname/datasetname, orduan ezin izango duzu muntatutako karpetan idatzi /poolname/datasetname 100 GiB baino gehiago.
Lerro bakoitzaren hasieran barraren presentzia -eta eza- nabarituko duzu? Datu-multzo bakoitzak bere lekua du bai ZFS hierarkian, bai sistema muntatzeko hierarkian. ZFS hierarkian ez dago barra nagusirik - igerilekuaren izenarekin hasten zara eta ondoren datu-multzo batetik besterako bidea. Adibidez, pool/parent/child izeneko datu multzo baterako child datu-multzo nagusiaren azpian parent sormen izena duen igerileku batean pool.
Lehenespenez, datu-multzoaren muntatze-puntua ZFS hierarkian bere izenaren baliokidea izango da, barra-barra batekin - izeneko multzoa. pool gisa muntatua /pool, datu multzoa parent barruan muntatuta /pool/parent, eta haurren datu-multzoa child barruan muntatuta /pool/parent/child. Hala ere, datu-multzoaren sistemaren muntatze-puntua alda daiteke.
Zehazten badugu zfs set mountpoint=/lol pool/parent/child, gero datu multzoa pool/parent/child sisteman muntatuta bezala /lol.
Datu multzoez gain, bolumenak (zvols) aipatu behar ditugu. Bolumen bat datu-multzo baten berdina da gutxi gorabehera, izan ezik, ez dauka fitxategi-sistemarik; bloke-gailu bat besterik ez da. Esaterako, sortu dezakezu zvol Izenarekin mypool/myzvol, ondoren formateatu ext4 fitxategi-sistema batekin, eta muntatu fitxategi-sistema hori - orain ext4 fitxategi-sistema bat duzu, baina ZFS-ren segurtasun-ezaugarri guztiekin! Honek tontoa dirudi makina bakarrean, baina askoz zentzu handiagoa du backend gisa iSCSI gailu bat esportatzean.
bloke
Fitxategia bloke batek edo gehiagok adierazten du. Bloke bakoitza gailu birtual batean gordetzen da. Blokearen tamaina normalean parametroaren berdina da erregistroaren tamaina, baina horretara murriztu daiteke 2^ txandametadatuak edo fitxategi txiki bat baditu.
Gu benetan benetan ez txantxetan errendimendu-zigor handiari buruz txantxa txikiegia ezartzen baduzu
ZFS multzo batean, datu guztiak, metadatuak barne, blokeetan gordetzen dira. Datu-multzo bakoitzeko bloke-tamaina maximoa propietatean zehazten da recordsize (erregistroaren tamaina). Erregistroaren tamaina alda daiteke, baina honek ez du aldatuko datu-multzoan dagoeneko idatzita dauden blokeen tamaina edo kokapena - idazten diren heinean bloke berriei bakarrik eragiten die.
Besterik zehaztu ezean, uneko erregistro-tamaina lehenetsia 128 KiB da. Errendimendua perfektua ez den truke delikatua da, baina kasu gehienetan ere ez da izugarria. Recordsize 4K eta 1M bitarteko edozein baliotan ezar daiteke (ezarpen aurreratuekin recordsize are gehiago instalatu dezakezu, baina hori oso gutxitan da ideia ona).
Edozein bloke fitxategi bakarreko datuak aipatzen ditu; ezin dituzu bi fitxategi ezberdin bildu bloke batean. Fitxategi bakoitzak bloke bat edo gehiago ditu, tamainaren arabera. Fitxategiaren tamaina erregistroaren tamaina baino txikiagoa bada, bloke tamaina txikiagoan gordeko da; adibidez, 2 KiB fitxategia duen bloke batek 4 KiB sektore bakarra okupatuko du diskoan.
Fitxategia nahikoa handia bada eta hainbat bloke behar baditu, fitxategi hau duten erregistro guztiak tamainakoak izango dira recordsize - azken sarrera barne, zati nagusia izan daitekeena .
zvolek ez dute jabetzarik recordsize β horren ordez propietate baliokidea dute volblocksize.
Sektoreak
Azken elementurik oinarrizkoena sektorea da. Azpiko gailuan idatzi edo irakur daitekeen unitate fisikorik txikiena da. Hainbat hamarkadatan, disko gehienek 512 byteko sektoreak erabili zituzten. Duela gutxi, disko gehienak 4 KiB sektoreetarako konfiguratuta daude, eta batzuek -batez ere SSDek- 8 KiB sektore edo are gehiago dituzte.
ZFS sistemak sektorearen tamaina eskuz ezartzeko aukera ematen duen propietate bat du. Jabetza hau ashift. Zertxobait nahasgarria den moduan, ashift biren boterea da. Adibidez, ashift=9 2^9 edo 512 byteko sektorearen tamaina esan nahi du.
ZFS-k sistema eragileari galdetzen dio bloke-gailu bakoitzari buruzko informazio zehatza Vdev berri batera gehitzen denean, eta teorikoki ashift behar bezala instalatzen du informazio horretan oinarrituta. Zoritxarrez, unitate askok beren sektorearen tamainari buruz gezurra egiten dute Windows XP-rekin bateragarritasuna mantentzeko (ezin zituen beste sektore-tamainetako unitateak ulertu).
Horrek esan nahi du ZFSko administratzaile bati bere gailuen benetako sektorearen tamaina ezagutzea eta eskuz ezartzea gomendatzen zaiola. ashift. Ashift baxuegia ezartzen bada, irakurketa/idazketa eragiketa kopurua astronomikoki handitzen da. Beraz, 512 byteko "sektoreak" 4 KiBko sektore erreal batean idazteak esan nahi du lehenengo "sektorea" idatzi behar izatea, ondoren 4 KiB sektorea irakurri, bigarren 512 byteko "sektore batekin" aldatu, berriro idatzi 4 KiB sektorea, eta abar sarrera bakoitzeko.
Mundu errealean, halako zigorrak Samsung EVO SSDak jotzen ditu, eta horretarako ashift=13, baina SSD hauek beren sektorearen tamainari buruzko gezurra da, eta, beraz, lehenetsia ezarrita dago ashift=9. Esperientziadun sistema-administratzaile batek ezarpen hau aldatzen ez badu, SSD honek funtzionatuko du motelago HDD magnetiko konbentzionala.
Konparaziorako, tamaina handiegietarako ashift ia ez dago zigorrik. Ez dago benetako errendimendu zigorrik, eta erabili gabeko espazioaren gehikuntza infinitesimala da (edo zero konpresioa gaituta dagoenean). Hori dela eta, 512 byteko sektoreak erabiltzen dituzten unitateak ere instalatzea gomendatzen dugu ashift=12 edo are ashift=13etorkizunari konfiantzaz aurre egiteko.
jabetza ashift vdev gailu birtual bakoitzerako ezartzen da, eta ez igerilekurako, askok oker uste duten bezala - eta ez da aldatzen instalatu ondoren. Ustekabean jo baduzu ashift igerileku batean vdev berri bat gehitzen duzunean, errendimendu baxuko gailu batekin igerileku hori kutsatu duzu eta normalean igerilekua suntsitu eta berriro hastea beste aukerarik ez dago. vdev kenduta ere ez zaitu salbatuko hautsitako konfigurazio batetik ashift!
Kopiatu idazteko mekanismoa
Fitxategi sistema arrunt batek datuak gainidatzi behar baditu, bloke bakoitza non dagoen aldatzen du
Kopiatu-idazketako fitxategi-sistema batek bloke-bertsio berri bat idazten du eta gero bertsio zaharra desblokeatzen du
Laburbilduz, blokeen benetako kokapen fisikoa alde batera uzten badugu, orduan gure "datu kometa" sinplifikatu egiten da "datu-harra" batera, ezkerretik eskuinera mugitzen den espazio erabilgarriaren mapan zehar.
Orain, kopia-idazketako argazkien funtzionamenduari buruzko ideia ona izan dezakegu - bloke bakoitza argazki anitzetakoa izan daiteke, eta atxikitako argazki guztiak suntsitu arte iraungo du.
Copy on Write (CoW) mekanismoa ZFS sistema harrigarria bihurtzen duenaren oinarrizko oinarria da. Oinarrizko kontzeptua erraza da: fitxategi-sistema tradizional bati fitxategi bat aldatzeko eskatzen badiozu, zuk eskatutakoa egingo du. Kopiatu-idazketako fitxategi-sistema bati gauza bera egiteko eskatzen badiozu, "ok" esango dizu, baina gezurra esango dizu.
Horren ordez, kopia-idazketa-fitxategi-sistema batek aldatutako blokearen bertsio berri bat idazten du eta, ondoren, fitxategiaren metadatuak eguneratzen ditu bloke zaharra lotzeko eta idatzi berri duzun bloke berria lotzeko.
Bloke zaharra kentzea eta berria lotzea eragiketa batean egiten da, beraz, ezin da eten - hau gertatu ondoren itzaltzen baduzu, fitxategiaren bertsio berri bat duzu eta hasieran itzaltzen baduzu, bertsio zaharra duzu. . Nolanahi ere, ez da gatazkarik egongo fitxategi-sisteman.
ZFSn kopia-idazketa fitxategi-sistemaren mailan ez ezik, diskoaren kudeaketa mailan ere gertatzen da. Horrek esan nahi du ZFS ez duela zuriuneak eragiten () - bandak sistema huts egin baino lehen partzialki bakarrik grabatzeko denbora izan zuen fenomenoa, berrabiarazi ondoren array-aren kalteekin. Hemen marra atomikoki idazten da, vdev beti sekuentziala da, eta .
ZIL: ZFS asmoen erregistroa
ZFS sistemak modu berezi batean tratatzen ditu idazketa sinkronoak - aldi baterako baina berehala gordetzen ditu ZIL-en, gero behin betiko idatzi aurretik idazketa asinkronoekin batera.
Normalean, ZIL batean idatzitako datuak ez dira berriro irakurtzen. Baina posible da sistemaren hutsegite baten ondoren
SLOG, edo bigarren mailako LOG gailua, vdev berezi bat da, eta ahal dela oso azkarra, non ZIL biltegiratze nagusitik bereizita gorde daitekeen.
Matxura baten ondoren, ZIL-eko datu zikin guztiak berriro erreproduzitzen dira; kasu honetan, ZIL SLOG-en dago, beraz, bertatik erreproduzitzen da
Idazketa-eragiketen bi kategoria nagusi daude: sinkronoak (sync) eta asinkronoak (async). Lan-karga gehienetarako, idazketa gehien-gehienak asinkronoak dira; fitxategi-sistemak multzoka eta multzoka igor daitezke, zatiketa murriztuz eta karga asko handituz.
Grabazio sinkronizatuak guztiz bestelako kontua dira. Aplikazio batek idazketa sinkronikoa eskatzen duenean, honela esaten dio fitxategi sistemari: "Memoria ez-hegazkorrarekin konprometitu behar duzu. oraintxe bertanordura arte, ez dut beste ezer eginΒ». Hori dela eta, idazketa sinkronoak diskoan konprometitu behar dira berehala, eta horrek zatiketa handitzen badu edo errendimendua murrizten badu, hala izan dadila.
ZFS-k fitxategi-sistema arruntek baino modu ezberdinean kudeatzen ditu idazketa sinkronoak; berehala biltegiratze arruntera konprometitu beharrean, ZFS-k ZFS Intent Log edo ZIL izeneko biltegiratze eremu berezi batera konprometitzen ditu. Trikimailua da erregistro horiek Era berean, memorian geratzen dira, idazketa-eskaera asinkrono arruntekin batera gehituta, gero biltegiratze TXG (Transaction Groups) guztiz normal gisa kargatzeko.
Funtzionamendu arruntean, ZIL idazten da eta ez da berriro irakurtzen. Momentu batzuk igaro ondoren, ZIL-eko erregistroak RAM-eko TXG arruntetan biltegiratze nagusian konprometitzen direnean, ZILetik deskonektatzen dira. ZILetik zerbait irakurtzen den aldi bakarra igerilekua inportatzen denean da.
ZFS-k huts egiten badu (sistema eragilearen hutsegite bat edo elektrizitatearen eten bat) ZIL-en datuak dauden bitartean, datu horiek hurrengo igerilekua inportatzean irakurriko dira (adibidez, larrialdi-sistema berrabiarazten duzunean). ZIL-an dagoen edozer irakurriko da, TXGetan taldekatuta, biltegiratze nagusiarekin konprometituko da eta, ondoren, ZILetik kenduko da inportazio prozesuan.
Vdev laguntzaile klaseetako bat LOG edo SLOG deitzen da, LOG-ren bigarren mailako gailua. Helburu bat du: igerilekuari Vdev bereizi bat eskaintzea, eta hobe askoz azkarragoa, oso idazteko erresistentea, ZIL gordetzeko, ZIL vdev denda nagusian gorde beharrean. ZILak berak portaera berdina du gordetzen den edozein lekutan, baina LOG vdev-ak idazketa-errendimendu oso altua badu, idazketa sinkronoak azkarragoak izango dira.
LOG duen vdev bat igerilekuan gehitzeak ez du funtzionatzen ezin hobetu idazketa asinkronoaren errendimendua - ZIL-ra idazketa guztiak behartzen badituzu ere zfs set sync=always, oraindik ere TXGko biltegiratze nagusiarekin lotuta egongo dira erregistrorik gabe bezala eta erritmo berean. Zuzeneko errendimenduaren hobekuntza bakarra idazketa sinkronikoen latentzia da (erregistro azkarragoak eragiketak bizkortzen dituelako). sync).
Hala ere, dagoeneko idazketa sinkrono asko eskatzen duen ingurune batean, vdev LOG-ek zeharka bizkor ditzake idazketa asinkronoak eta cachean ez dauden irakurketak. ZIL sarrerak vdev LOG bereizi batera deskargatzeak biltegiratze nagusian IOPS-entzako liskar gutxiago dakar, eta horrek irakurketa eta idazketa guztien errendimendua hobetzen du neurri batean.
Argazkiak
Kopiatu-idazketa mekanismoa ZFS argazki atomikoetarako eta erreplikazio asinkrono inkrementalerako beharrezko oinarria da. Fitxategi-sistema aktiboak erakusle-zuhaitz bat du erregistro guztiak uneko datuekin markatzen dituena; argazki bat ateratzen duzunean, erakusle-zuhaitz honen kopia bat besterik ez duzu egin.
Erregistro bat fitxategi-sistema aktiboan gainidazten denean, ZFS-k lehenik bloke bertsio berria idazten du erabili gabeko espazioan. Ondoren, blokearen bertsio zaharra uneko fitxategi-sistematik kentzen du. Baina argazki batzuk bloke zaharrari erreferentzia egiten badiote, oraindik aldatu gabe jarraitzen du. Bloke zaharra ez da espazio libre gisa leheneratuko bloke honi erreferentzia egiten dioten argazki guztiak suntsitu arte!
Erreplikatzea
Nire Steam liburutegia 2015ean 158 GiB zen eta 126 fitxategi zituen. Hau rsync-erako egoera optimotik gertu dago - ZFS sarearen bidezko erreplikazioa % 927 azkarragoa zen "soilik".
Sare berean, 40 GB-ko Windows 7 makina birtualeko irudi-fitxategi bakar bat errepikatzea guztiz bestelakoa da. ZFS erreplikazioa rsync baino 289 aldiz azkarragoa da, edo "soilik" 161 aldiz azkarragoa bada rsync --inplace-rekin deitzeko aski jakintsua bazara.
VM irudi bat eskalatzen denean, rsync arazoak berarekin eskalatzen dira. 1,9 TiB ez da hain handia VM irudi moderno baterako - baina nahikoa da ZFS erreplikazioa rsync baino 1148 aldiz azkarragoa izatea, nahiz eta rsync-en --inplace argumentuarekin
Argazkiak nola funtzionatzen duen ulertzen duzunean, erraza izan beharko litzateke erreplikazioaren funtsa ulertzea. Argazki bat erregistroen erakusleen zuhaitza besterik ez denez, hori egiten badugu zfs send argazkia, ondoren zuhaitz hau eta harekin lotutako erregistro guztiak bidaltzen ditugu. Hau bidaltzen dugunean zfs send Π² zfs receive xedean, blokearen benetako edukia eta helburuko datu multzoari blokeei erreferentzia egiten dien erakusleen zuhaitza idazten ditu.
Gauzak are interesgarriagoak dira bigarrenean zfs send. Orain bi sistema ditugu, bakoitzak dituena poolname/datasetname@1, eta argazki berri bat ateratzen duzu poolname/datasetname@2. Hori dela eta, jatorrizko igerilekuan duzu datasetname@1 ΠΈ datasetname@2, eta helburuko igerilekuan orain arte lehen argazkia bakarrik datasetname@1.
Iturburuaren eta xedearen artean argazki komun bat daukagunez datasetname@1, egin dezakegu inkrementala zfs send gainetik. Sistemari esaten diogunean zfs send -i poolname/datasetname@1 poolname/datasetname@2, bi erakusle zuhaitz konparatzen ditu. Bertan bakarrik existitzen diren erakusle guztiak @2, jakina, bloke berriei erreferentzia egiten diegu, beraz, bloke horien edukia behar dugu.
Urruneko sistema batean, inkremental bat prozesatzen send bezain sinplea. Lehenik eta behin korrontean sartutako sarrera berri guztiak idazten ditugu send, eta gehitu erakusleak bloke horiei. Voila, badugu @2 sistema berrian!
ZFS erreplika inkremental asinkronoa hobekuntza handia da rsync bezalako argazkietan oinarritutakoak ez diren metodoekiko. Bi kasuetan, aldatutako datuak soilik transferitzen dira, baina rsync-ek behar du lehenik irakurri diskotik bi aldeetako datu guztiak batura egiaztatzeko eta konparatzeko. Aitzitik, ZFS erreplikazioak erakusleen zuhaitzak baino ez ditu irakurtzen, eta partekatutako argazkian ez dauden blokeak.
Konpresio integratua
Kopiatu-idazketa mekanismoak lineako konpresio-sistema ere errazten du. Fitxategi-sistema tradizional batean, konpresioa arazotsua da - aldatutako datuen bertsio zaharra eta bertsio berria espazio berean daude.
0x00000000 eta abarretik zero megabyte gisa hasten den fitxategi baten erdian dagoen datu bat kontuan hartzen badugu, oso erraza da diskoko sektore batean konprimitzea. Baina zer gertatzen da zeroen megabyte hori JPEG edo sasi-ausazko zarata bezalako datu konprimiezinen megabyte batekin ordezkatzen badugu? Ustekabean, datu-megabyte honek ez du bat, 256 4 KiB sektore beharko ditu, eta diskoko leku honetan sektore bakarra dago erreserbatuta.
ZFS-k ez du arazo hau, aldatutako erregistroak beti erabiltzen ez den espazioan idazten baitira - jatorrizko blokeak 4 KiB sektore bakarra hartzen du eta erregistro berriak 256 okupatuko ditu, baina hau ez da arazoa - duela gutxi aldatutako zati bat " Fitxategiaren erdian" erabili gabeko espazioan idatziko litzateke bere tamaina aldatu den ala ez kontuan hartu gabe, beraz, ZFSrentzat egoera nahiko arrunta da.
ZFS konpresio natiboa desgaituta dago lehenespenez, eta sistemak konekta daitezkeen algoritmoak eskaintzen ditu, gaur egun LZ4, gzip (1-9), LZJB eta ZLE.
- LZ4 konpresio eta deskonpresio eta errendimendu onurak eskaintzen dituen streaming algoritmoa da, erabilera kasu gehienetarako, nahiz eta CPU nahiko moteletan.
- GZIP Unix-eko erabiltzaile guztiek ezagutzen eta maite duten algoritmo agurgarria da. 1-9 konpresio-mailekin inplementa daiteke, konpresio-erlazioa eta PUZaren erabilera areagotuz 9. mailara hurbiltzen den heinean. Algoritmoa oso egokia da testu-kasu guztietarako (edo oso konprimagarriak diren beste) erabilera-kasuetarako, baina bestela askotan CPU arazoak sortzen ditu - erabili kontu handiz, goi mailako mailetan batez ere.
- LZJB ZFSko jatorrizko algoritmoa da. Zaharkituta dago eta ez da gehiago erabili behar, LZ4-k alde guztietan gainditzen du.
- GAIZKI - zero maila kodetzea, zero maila kodetzea. Ez ditu datu normalak batere ukitzen, baina zero sekuentzia handiak konprimitzen ditu. Erabat konprimi ezin diren datu-multzoetarako (adibidez, JPEG, MP4 edo dagoeneko konprimitutako beste formatu batzuetarako) erabilgarria da, datu konprimigaitzak alde batera uzten baititu, baina ondoriozko erregistroetan erabili gabeko espazioa konprimitzen baitu.
Ia erabilera kasu guztietarako LZ4 konpresioa gomendatzen dugu; errendimendu-zigorra datu konprimiezinak topatzean oso txikia da, eta hazkundea datu arruntetarako errendimendua esanguratsua da. Windows sistema eragilearen instalazio berri baterako makina birtualaren irudia kopiatzea (instalatutako sistema eragilea, oraindik ez dago daturik) honekin compression=lz4 rekin baino %27 azkarrago pasatu da compression=nonein .
ARC - ordezko cache moldagarria
ZFS ezagutzen dugun fitxategi-sistema moderno bakarra da, irakurtzeko cache-mekanismo propioa erabiltzen duena, sistema eragilearen orrialde-cachean fidatu beharrean, irakurri berri diren blokeen kopiak RAMan gordetzeko.
Nahiz eta jatorrizko cachea arazorik gabe egon - ZFS-k ezin du memoria esleipen eskaera berriei kernelak bezain azkar erantzun, beraz, erronka berria malloc() memoria-esleipenean huts egin dezake ARC-ek une honetan okupatutako RAM behar badu. Baina arrazoi onak daude zure cachea erabiltzeko, oraingoz behintzat.
Ezagutzen diren sistema eragile moderno guztiek, MacOS, Windows, Linux eta BSD barne, LRU (Erabilitako gutxien) algoritmoa erabiltzen dute orrialdeen cachea ezartzeko. Algoritmo primitibo bat da, irakurketa bakoitzaren ondoren cache-ko blokea "ilaran gora" bultzatzen duena, eta blokeak "ilaran behera" bultzatzen dituena, behar den moduan, cache hutsak gehitzeko (diskotik irakurri behar ziren blokeak, ez cachetik) gora.
Algoritmoak ondo funtzionatzen du normalean, baina laneko datu-multzo handiak dituzten sistemetan, LRUk erraz eragiten du thrashing - maiz behar diren blokeak kanporatuz, cachetik berriro irakurriko ez diren blokeei lekua egiteko.
askoz ere gutxiago inozoa den algoritmoa da, cache "haztatu" gisa har daitekeena. Cachean gordetako bloke bat irakurtzen den bakoitzean, pixka bat "astunagoa" eta zailagoa egiten da kanporatzea, baita bloke bat desalojatu ondoren ere. jarraipena egin epe jakin baten barruan. Desalojatu baina gero cachean berriro irakurri behar den bloke bat ere "astunagoa" bihurtuko da.
Honen guztiaren azken emaitza hit ratio askoz handiagoa duen cachea da, cache-aren arrakastaren (cachetik egindako irakurketak) eta cache hutsen (diskotik irakurtzen diren) arteko erlazioa. Hau oso estatistiko garrantzitsua da - cache-aren arrakastak berez tamaina-aginduak bizkorrago hornitzeaz gain, cache-hutsak bizkorrago ere horni daitezke, izan ere, zenbat eta cache-ren arrakasta gehiago egon, orduan eta disko eskaera aldi berean gutxiago eta latentzia txikiagoa izango da gainerako hutsegite horientzat. diskoarekin zerbitzatu behar dena.
Ondorioa
ZFSren oinarrizko semantika ikasi ondoren - kopia-idazketa nola funtzionatzen duen, baita biltegiratze-taldeen, gailu birtualen, blokeen, sektoreen eta fitxategien arteko erlazioak ere - prest gaude mundu errealeko errendimendua zenbaki errealekin eztabaidatzeko.
Hurrengo zatian, ispiludun vdevs eta RAIDz dituzten igerilekuen benetako errendimendua ikusiko dugu, bata bestearen aldean, eta arakatu ditugun Linux kernel RAID topologien aldean. .
Hasieran, oinarriak soilik - ZFS topologiak beraiek - baina ondoren hala nola presta gaitezen ZFS-ren konfigurazio eta sintonizazio aurreratuagoei buruz hitz egiteko, L2ARC, SLOG eta Esleipen Berezia bezalako vdev mota osagarrien erabilera barne.
Iturria: www.habr.com