Y gwanwyn hwn rydym eisoes wedi trafod rhai pynciau rhagarweiniol, er enghraifft, и . Yn yr ail ohonynt, gwnaethom hyd yn oed addo parhau i astudio perfformiad topolegau aml-ddisg amrywiol yn ZFS. Dyma system ffeiliau'r genhedlaeth nesaf sydd bellach yn cael ei gweithredu ym mhobman: o i .
Wel, heddiw yw'r diwrnod gorau i ddod yn gyfarwydd â ZFS, darllenwyr chwilfrydig. Dim ond yn gwybod bod ym marn ostyngedig datblygwr OpenZFS Matt Ahrens, "mae'n anodd iawn."
Ond cyn i ni gyrraedd y niferoedd - a byddant, rwy'n addo - ar gyfer pob opsiwn ar gyfer cyfluniad ZFS wyth disg, mae angen i ni siarad am как Yn gyffredinol, mae ZFS yn storio data ar ddisg.
Zpool, vdev a dyfais
Mae'r diagram cronfa llawn hwn yn cynnwys tri vdev ategol, un o bob dosbarth, a phedwar ar gyfer RAIDz2
Fel arfer does dim rheswm i greu cronfa o fathau a meintiau vdev nad ydynt yn cyfateb - ond does dim byd yn eich rhwystro rhag gwneud hynny os dymunwch.
I wir ddeall system ffeiliau ZFS, mae angen ichi edrych yn fanwl ar ei strwythur gwirioneddol. Yn gyntaf, mae ZFS yn uno'r lefelau traddodiadol o reoli cyfaint a system ffeiliau. Yn ail, mae'n defnyddio mecanwaith copi-ar-ysgrifennu trafodaethol. Mae'r nodweddion hyn yn golygu bod strwythur y system yn wahanol iawn i systemau ffeiliau confensiynol ac araeau RAID. Y set gyntaf o flociau adeiladu sylfaenol i'w deall yw'r pwll storio (zpool), dyfais rithwir (vdev), a dyfais go iawn (dyfais).
cwpwl
Y pwll storio zpool yw'r strwythur ZFS uchaf. Mae pob pwll yn cynnwys un neu fwy o ddyfeisiau rhithwir. Yn ei dro, mae pob un ohonynt yn cynnwys un neu fwy o ddyfeisiau go iawn (dyfais). Mae pyllau rhithwir yn flociau hunangynhwysol. Gall un cyfrifiadur corfforol gynnwys dau neu fwy o bwll ar wahân, ond mae pob un yn gwbl annibynnol ar y lleill. Ni all pyllau rannu dyfeisiau rhithwir.
Mae dileu swydd ZFS ar lefel dyfais rithwir, nid ar lefel y pwll. Nid oes unrhyw ddiswyddiadau ar lefel y pwll - os collir unrhyw yrru vdev neu vdev arbennig, yna mae'r pwll cyfan yn cael ei golli ynghyd ag ef.
Gall pyllau storio modern oroesi colli storfa neu log dyfais rithwir - er y gallant golli ychydig o ddata budr os byddant yn colli'r log vdev yn ystod toriad pŵer neu ddamwain system.
Mae yna gamsyniad cyffredin bod "streipiau data" ZFS wedi'u hysgrifennu ar draws y pwll cyfan. Nid yw hyn yn wir. Nid yw Zpool yn ddoniol RAID0 o gwbl, mae braidd yn ddoniol gyda mecanwaith dosbarthu amrywiol cymhleth.
Ar y cyfan, mae'r cofnodion yn cael eu dosbarthu ymhlith y dyfeisiau rhithwir sydd ar gael yn ôl y gofod rhad ac am ddim sydd ar gael, felly mewn theori byddant i gyd yn cael eu llenwi ar yr un pryd. Mewn fersiynau diweddarach o ZFS, mae'r defnydd vdev cyfredol (defnydd) yn cael ei ystyried - os yw un ddyfais rithwir gryn dipyn yn brysurach nag un arall (er enghraifft, oherwydd llwyth darllen), bydd yn cael ei hepgor dros dro ar gyfer ysgrifennu, er gwaethaf cael y mwyaf rhad ac am ddim cymhareb gofod.
Gall y mecanwaith canfod defnydd sydd wedi'i ymgorffori mewn dulliau dyrannu ysgrifennu ZFS modern leihau cuddni a chynyddu trwybwn yn ystod cyfnodau o lwyth anarferol o uchel - ond nid yw carte blanche ar gymysgu anwirfoddol o HDDs araf ac SSDs cyflym mewn un pwll. Bydd pwll anghyfartal o'r fath yn dal i weithredu ar gyflymder y ddyfais arafaf, hynny yw, fel pe bai'n gyfan gwbl yn cynnwys dyfeisiau o'r fath.
vdev
Mae pob pwll storio yn cynnwys un neu fwy o ddyfeisiau rhithwir (dyfais rithwir, vdev). Yn ei dro, mae pob vdev yn cynnwys un neu fwy o ddyfeisiau go iawn. Defnyddir y rhan fwyaf o ddyfeisiau rhithwir ar gyfer storio data syml, ond mae yna nifer o ddosbarthiadau cynorthwywyr vdev, gan gynnwys CACHE, LOG, ac ARBENNIG. Gall pob un o'r mathau hyn o vdev gael un o bum topoleg: dyfais sengl (dyfais sengl), RAIDz1, RAIDz2, RAIDz3, neu ddrych (drych).
Mae RAIDz1, RAIDz2 a RAIDz3 yn fathau arbennig o'r hyn y byddai'r hen amserwyr yn ei alw'n RAID cydraddoldeb dwbl (lletraws). Mae 1, 2 a 3 yn cyfeirio at faint o flociau cydraddoldeb sy'n cael eu dyrannu ar gyfer pob stribed data. Yn lle disgiau ar wahân ar gyfer cydraddoldeb, mae dyfeisiau rhithwir RAIDz yn dosbarthu'r cydraddoldeb hwn yn lled gyfartal ar draws disgiau. Gall arae RAIDz golli cymaint o ddisgiau ag sydd ganddi flociau cydraddoldeb; os bydd yn colli un arall, bydd yn chwalu ac yn mynd â'r pwll storio gydag ef.
Mewn dyfeisiau rhithwir a adlewyrchir (drych vdev), mae pob bloc yn cael ei storio ar bob dyfais yn y vdev. Er mai drychau dau lydan yw'r rhai mwyaf cyffredin, gall unrhyw nifer mympwyol o ddyfeisiadau fod mewn drych - defnyddir triphlyg yn aml mewn gosodiadau mawr i wella perfformiad darllen a goddefgarwch namau. Gall drych vdev oroesi unrhyw fethiant cyhyd â bod o leiaf un ddyfais yn y vdev yn parhau i weithredu.
Mae vdevs sengl yn gynhenid beryglus. Ni fydd dyfais rithwir o'r fath yn goroesi un methiant - ac os caiff ei ddefnyddio fel storfa neu vdev arbennig, yna bydd ei fethiant yn arwain at ddinistrio'r pwll cyfan. Byddwch yn ofalus iawn, iawn yma.
Gellir creu CACHE, LOG, a VAs ARBENNIG gan ddefnyddio unrhyw un o'r topolegau uchod - ond cofiwch fod colli VA ARBENNIG yn golygu colli'r pwll, felly argymhellir topoleg segur yn fawr.
dyfais
Mae'n debyg mai dyma'r term hawsaf i'w ddeall yn ZFS - yn llythrennol mae'n ddyfais mynediad hap bloc. Cofiwch fod dyfeisiau rhithwir yn cynnwys dyfeisiau unigol, tra bod pwll yn cynnwys dyfeisiau rhithwir.
Disgiau - naill ai cyflwr magnetig neu solet - yw'r dyfeisiau bloc mwyaf cyffredin a ddefnyddir fel blociau adeiladu vdev. Fodd bynnag, bydd unrhyw ddyfais sydd â disgrifydd yn /dev yn gwneud hynny, felly gellir defnyddio araeau RAID caledwedd cyfan fel dyfeisiau ar wahân.
Ffeil amrwd syml yw un o'r dyfeisiau bloc amgen pwysicaf y gellir adeiladu vdev ohono. Pyllau prawf o yn ffordd ddefnyddiol iawn o wirio gorchmynion pwll a gweld faint o le sydd ar gael mewn pwll neu ddyfais rithwir o dopoleg benodol.
Gallwch greu cronfa brawf o ffeiliau prin mewn ychydig eiliadau yn unig - ond peidiwch ag anghofio dileu'r pwll cyfan a'i gydrannau wedyn
Gadewch i ni ddweud eich bod am roi gweinydd ar wyth disg a chynllunio i ddefnyddio 10 disg TB (~ 9300 GiB) - ond nid ydych chi'n siŵr pa dopoleg sy'n gweddu orau i'ch anghenion. Yn yr enghraifft uchod, rydym yn adeiladu pwll prawf o ffeiliau prin mewn eiliadau - a nawr rydym yn gwybod bod vdev RAIDz2 o wyth disg 10 TB yn darparu 50 TiB o gapasiti defnyddiadwy.
Dosbarth arbennig arall o ddyfeisiadau yw SPARE (sbâr). Mae dyfeisiau cyfnewid poeth, yn wahanol i ddyfeisiau arferol, yn perthyn i'r pwll cyfan, ac nid i un ddyfais rithwir. Os bydd vdev yn y pwll yn methu a bod dyfais sbâr wedi'i chysylltu â'r pwll ac ar gael, yna bydd yn ymuno â'r vdev yr effeithir arno yn awtomatig.
Ar ôl cysylltu â'r vdev yr effeithir arno, mae'r ddyfais sbâr yn dechrau derbyn copïau neu adluniadau o'r data a ddylai fod ar y ddyfais sydd ar goll. Mewn RAID traddodiadol gelwir hyn yn ailadeiladu, tra yn ZFS fe'i gelwir yn ail-liwio.
Mae'n bwysig nodi nad yw dyfeisiau sbâr yn disodli dyfeisiau sydd wedi methu yn barhaol. Dim ond amnewidiad dros dro yw hwn i leihau faint o amser y mae vdev yn cael ei ddiraddio. Ar ôl i'r gweinyddwr ddisodli'r vdev a fethwyd, caiff diswyddiad ei adfer i'r ddyfais barhaol honno, a chaiff SPARE ei ddatgysylltu o'r vdev a'i ddychwelyd i'r gwaith fel sbâr ar gyfer y pwll cyfan.
Setiau data, blociau a sectorau
Mae'r set nesaf o flociau adeiladu i'w deall ar ein taith ZFS yn ymwneud llai â'r caledwedd a mwy am sut mae'r data ei hun yn cael ei drefnu a'i storio. Rydyn ni'n hepgor ychydig o lefelau yma - fel metaslab - er mwyn peidio ag annibendod y manylion wrth gynnal dealltwriaeth o'r strwythur cyffredinol.
Set ddata (set ddata)
Pan fyddwn yn creu set ddata gyntaf, mae'n dangos yr holl ofod cronfa sydd ar gael. Yna rydyn ni'n gosod y cwota - ac yn newid y pwynt gosod. Hud!
Ar y cyfan, dim ond set ddata yw Zvol sydd wedi'i thynnu o'i haen system ffeiliau, yr ydym yn ei disodli yma gyda system ffeiliau ext4 hollol normal.
Mae set ddata ZFS fwy neu lai yr un fath â system ffeiliau safonol wedi'i gosod. Fel system ffeiliau reolaidd, ar yr olwg gyntaf mae'n edrych fel "dim ond ffolder arall". Ond yn union fel systemau ffeiliau y gellir eu gosod yn rheolaidd, mae gan bob set ddata ZFS ei set ei hun o briodweddau sylfaenol.
Yn gyntaf oll, gall set ddata gael cwota wedi'i neilltuo. Os gosod zfs set quota=100G poolname/datasetname, yna ni fyddwch yn gallu ysgrifennu at y ffolder wedi'i osod /poolname/datasetname mwy na 100 GiB.
Sylwch ar bresenoldeb - ac absenoldeb - toriadau ar ddechrau pob llinell? Mae gan bob set ddata ei lle ei hun yn hierarchaeth ZFS a hierarchaeth gosod system. Nid oes unrhyw slaes arweiniol yn hierarchaeth ZFS - rydych chi'n dechrau gydag enw'r pwll ac yna'r llwybr o un set ddata i'r nesaf. Er enghraifft, pool/parent/child ar gyfer set ddata a enwir child o dan y set ddata rhiant parent mewn pwll ag enw creadigol pool.
Yn ddiofyn, bydd pwynt gosod y set ddata yn cyfateb i'w enw yn hierarchaeth ZFS, gyda slaes arweiniol - y pwll a enwir pool gosod fel /pool, set ddata parent wedi'i osod i mewn /pool/parent, a'r set ddata plentyn child wedi'i osod i mewn /pool/parent/child. Fodd bynnag, gellir newid pwynt gosod system y set ddata.
Os byddwn yn nodi zfs set mountpoint=/lol pool/parent/child, yna y set ddata pool/parent/child wedi'i osod ar y system fel /lol.
Yn ogystal â setiau data, dylem sôn am gyfrolau (zvols). Mae cyfaint yn fras yr un peth â set ddata, ac eithrio nad oes ganddi system ffeiliau mewn gwirionedd - dim ond dyfais bloc ydyw. Gallwch chi, er enghraifft, greu zvol Gydag enw mypool/myzvol, yna ei fformatio gyda system ffeiliau ext4, ac yna gosodwch y system ffeiliau honno - mae gennych chi system ffeil ext4 nawr, ond gyda holl nodweddion diogelwch ZFS! Gall hyn ymddangos yn wirion ar un peiriant, ond mae'n gwneud llawer mwy o synnwyr fel backend wrth allforio dyfais iSCSI.
Blociau
Cynrychiolir y ffeil gan un neu fwy o flociau. Mae pob bloc yn cael ei storio ar un ddyfais rithwir. Mae maint y bloc fel arfer yn hafal i'r paramedr maint cofnodion, ond gellir ei leihau i 2^ shifftos yw'n cynnwys metadata neu ffeil fach.
Rydym yn wir a dweud y gwir peidio cellwair am y gosb perfformiad enfawr os ydych yn gosod ashift rhy fach
Mewn cronfa ZFS, mae'r holl ddata, gan gynnwys metadata, yn cael ei storio mewn blociau. Mae maint bloc uchaf pob set ddata wedi'i ddiffinio yn yr eiddo recordsize (maint cofnod). Gellir newid maint y cofnod, ond ni fydd hyn yn newid maint na lleoliad unrhyw flociau sydd eisoes wedi'u hysgrifennu i'r set ddata - dim ond blociau newydd y mae'n effeithio arnynt wrth iddynt gael eu hysgrifennu.
Oni nodir yn wahanol, maint y cofnod rhagosodedig cyfredol yw 128 KiB. Mae'n fath o gyfaddawd dyrys lle nad yw perfformiad yn berffaith, ond nid yw'n ofnadwy yn y rhan fwyaf o achosion ychwaith. Recordsize gellir ei osod i unrhyw werth o 4K i 1M (gyda gosodiadau uwch recordsize gallwch chi osod hyd yn oed mwy, ond anaml y mae hyn yn syniad da).
Mae unrhyw floc yn cyfeirio at ddata un ffeil yn unig - ni allwch glymu dwy ffeil wahanol yn un bloc. Mae pob ffeil yn cynnwys un bloc neu fwy, yn dibynnu ar y maint. Os yw maint y ffeil yn llai na maint y cofnod, bydd yn cael ei storio mewn maint bloc llai - er enghraifft, bydd bloc gyda ffeil 2 KiB yn meddiannu dim ond un sector 4 KiB ar y ddisg.
Os yw'r ffeil yn ddigon mawr ac angen sawl bloc, yna bydd yr holl gofnodion gyda'r ffeil hon o faint recordsize — yn cynnwys y cofnodiad olaf, y gall y prif ran o hono fod .
nid oes gan zvols eiddo recordsize — yn lle hynny mae ganddynt eiddo cyfatebol volblocksize.
Sectorau
Y bloc adeiladu olaf, mwyaf sylfaenol yw'r sector. Dyma'r uned gorfforol leiaf y gellir ei hysgrifennu neu ei darllen o'r ddyfais waelodol. Am sawl degawd, defnyddiodd y rhan fwyaf o ddisgiau sectorau 512-beit. Yn ddiweddar, mae'r rhan fwyaf o ddisgiau wedi'u gosod i 4 sector KiB, ac mae gan rai - yn enwedig SSDs - sectorau 8 KiB neu hyd yn oed mwy.
Mae gan y system ZFS eiddo sy'n eich galluogi i osod maint y sector â llaw. Yr eiddo hwn ashift. Braidd yn ddryslyd, mae symud yn bŵer o ddau. Er enghraifft, ashift=9 yn golygu maint sector o 2^9, neu 512 beit.
Mae ZFS yn holi'r system weithredu am wybodaeth fanwl am bob dyfais bloc pan gaiff ei hychwanegu at vdev newydd, ac yn ddamcaniaethol mae'n gosod ashift yn awtomatig yn seiliedig ar y wybodaeth honno. Yn anffodus, mae llawer o yrwyr yn dweud celwydd am eu maint sector er mwyn cynnal cydnawsedd â Windows XP (nad oedd yn gallu deall gyriannau â meintiau sector eraill).
Mae hyn yn golygu bod gweinyddwr ZFS yn cael ei gynghori'n gryf i wybod maint sector gwirioneddol eu dyfeisiau a'u gosod â llaw ashift. Os yw symud yn cael ei osod yn rhy isel, yna mae nifer y gweithrediadau darllen / ysgrifennu yn cynyddu'n seryddol. Felly, mae ysgrifennu "sectorau" 512-beit i mewn i sector 4 KiB go iawn yn golygu gorfod ysgrifennu'r "sector" cyntaf, yna darllenwch y sector 4 KiB, ei addasu gydag ail "sector" 512-byte, ei ysgrifennu yn ôl i'r newydd 4 sector KiB, ac yn y blaen ar gyfer pob cais.
Yn y byd go iawn, mae cosb o'r fath yn taro Samsung EVO SSDs, y mae hynny ashift=13, ond mae'r SSDs hyn yn gorwedd am faint eu sector, ac felly mae'r rhagosodiad wedi'i osod i ashift=9. Os nad yw gweinyddwr system profiadol yn newid y gosodiad hwn, yna mae'r SSD hwn yn gweithio arafach HDD magnetig confensiynol.
Er mwyn cymharu, ar gyfer maint rhy fawr ashift nid oes bron unrhyw gosb. Nid oes cosb perfformiad go iawn, ac mae'r cynnydd mewn gofod nas defnyddiwyd yn anfeidrol (neu sero gyda chywasgu wedi'i alluogi). Felly, rydym yn argymell yn gryf bod hyd yn oed y gyriannau hynny sy'n defnyddio sectorau 512-beit yn gosod ashift=12 neu hyd yn oed ashift=13wynebu’r dyfodol yn hyderus.
Eiddo ashift yn cael ei osod ar gyfer pob dyfais rhith vdev, a nid ar gyfer y pwll, gan fod llawer yn meddwl ar gam - ac nid yw'n newid ar ôl ei osod. Os ydych chi'n taro'n ddamweiniol ashift pan fyddwch chi'n ychwanegu vdev newydd i bwll, rydych chi wedi llygru'r pwll hwnnw'n anadferadwy gyda dyfais perfformiad isel ac fel arfer nid oes unrhyw ddewis arall ond dinistrio'r pwll a dechrau drosodd. Ni fydd tynnu vdev hyd yn oed yn eich arbed rhag cyfluniad sydd wedi torri ashift!
Mecanwaith copi-ar-ysgrifennu
Os oes angen i system ffeiliau reolaidd drosysgrifo data, mae'n newid pob bloc lle mae
Mae system ffeiliau copi-ar-ysgrifennu yn ysgrifennu fersiwn bloc newydd ac yna'n datgloi'r hen fersiwn
Yn y crynodeb, os ydym yn anwybyddu lleoliad ffisegol gwirioneddol y blociau, yna mae ein "comet data" yn cael ei symleiddio i "mwydyn data" sy'n symud o'r chwith i'r dde ar draws y map o'r gofod sydd ar gael
Nawr gallwn gael syniad da o sut mae cipluniau copi-ar-ysgrifennu yn gweithio - gall pob bloc berthyn i gipluniau lluosog, a bydd yn parhau nes bod yr holl gipluniau cysylltiedig yn cael eu dinistrio
Y mecanwaith Copy on Write (CoW) yw sail sylfaenol yr hyn sy'n gwneud ZFS yn system mor anhygoel. Mae'r cysyniad sylfaenol yn syml - os gofynnwch i system ffeiliau draddodiadol newid ffeil, bydd yn gwneud yn union yr hyn a ofynnoch. Os byddwch yn gofyn i system ffeiliau copi-ar-ysgrifennu wneud yr un peth, bydd yn dweud "iawn" ond celwydd wrthych.
Yn lle hynny, mae system ffeiliau copi-ar-ysgrifennu yn ysgrifennu fersiwn newydd o'r bloc wedi'i addasu ac yna'n diweddaru metadata'r ffeil i ddatgysylltu'r hen floc a chysylltu'r bloc newydd yr ydych newydd ei ysgrifennu ato.
Mae datgysylltu'r hen floc a chysylltu'r un newydd yn cael ei wneud mewn un llawdriniaeth, felly ni ellir ymyrryd â hi - os byddwch chi'n pweru i lawr ar ôl i hyn ddigwydd, mae gennych chi fersiwn newydd o'r ffeil, ac os byddwch chi'n pweru i lawr yn gynnar, mae gennych chi'r hen fersiwn . Mewn unrhyw achos, ni fydd unrhyw wrthdaro yn y system ffeiliau.
Mae copi-ar-ysgrifennu yn ZFS yn digwydd nid yn unig ar lefel y system ffeiliau, ond hefyd ar lefel rheoli disg. Mae hyn yn golygu nad yw gofod gwyn yn effeithio ar ZFS () - ffenomen pan oedd gan y stribed amser i gofnodi'n rhannol yn unig cyn i'r system chwalu, gyda difrod arae ar ôl ailgychwyn. Yma mae'r streipen wedi'i hysgrifennu'n atomig, mae vdev bob amser yn ddilyniannol, a .
ZIL: Log bwriad ZFS
Mae'r system ZFS yn trin ysgrifeniadau cydamserol mewn ffordd arbennig - mae'n eu storio dros dro yn ZIL ar unwaith cyn eu hysgrifennu'n barhaol yn ddiweddarach ynghyd ag ysgrifennau asyncronig.
Yn nodweddiadol, nid yw data a ysgrifennwyd i ZIL byth yn cael ei ddarllen eto. Ond mae'n bosibl ar ôl damwain system
Mae SLOG, neu ddyfais LOG eilaidd, yn vdev arbennig - ac yn gyflym iawn yn ddelfrydol -, lle gellir storio'r ZIL ar wahân i'r prif storfa
Ar ôl damwain, mae'r holl ddata budr yn ZIL yn cael ei ailchwarae - yn yr achos hwn, mae ZIL ar SLOG, felly mae'n cael ei ailchwarae oddi yno
Mae dau brif gategori o weithrediadau ysgrifennu - cydamserol (cysoni) ac asyncronig (async). Ar gyfer y rhan fwyaf o lwythi gwaith, mae mwyafrif helaeth yr ysgrifenniadau yn asyncronig - mae'r system ffeiliau yn caniatáu iddynt gael eu hagregu a'u dosbarthu mewn sypiau, gan leihau darnio a chynyddu'r mewnbwn yn sylweddol.
Mae recordiadau cydamserol yn fater hollol wahanol. Pan fydd rhaglen yn gofyn am ysgrifen cydamserol, mae'n dweud wrth y system ffeiliau: "Mae angen i chi ymrwymo hyn i gof anweddol ar hyn o brydtan hynny, does dim byd arall y gallaf ei wneud." Felly, dylid ymrwymo ysgrifenniadau cydamserol i ddisg ar unwaith - ac os yw hynny'n cynyddu darnio neu'n lleihau trwybwn, yna bydded felly.
Mae ZFS yn trin ysgrifeniadau cydamserol yn wahanol na systemau ffeiliau rheolaidd - yn lle eu hymrwymo ar unwaith i storio rheolaidd, mae ZFS yn eu hymrwymo i ardal storio arbennig o'r enw Log Bwriad ZFS, neu ZIL. Y tric yw bod y cofnodion hyn hefyd aros yn y cof, yn cael ei agregu ynghyd â cheisiadau ysgrifennu asyncronaidd arferol, i'w fflysio'n ddiweddarach i storfa fel TXGs (Trafodion Groups) cwbl arferol.
Mewn gweithrediad arferol, ysgrifennir at y ZIL a pheidiwch byth â'i darllen eto. Pan, ar ôl ychydig eiliadau, mae'r cofnodion o'r ZIL wedi'u hymrwymo i'r prif storfa mewn TXGs arferol o RAM, maent yn cael eu gwahanu oddi wrth y ZIL. Yr unig amser y darllenir rhywbeth o'r ZIL yw pan fydd y pwll yn cael ei fewnforio.
Os bydd ZFS yn methu - damwain system weithredu neu doriad pŵer - tra bod data yn y ZIL, bydd y data hwnnw'n cael ei ddarllen yn ystod y mewnforio pwll nesaf (er enghraifft, wrth ailgychwyn y system argyfwng). Bydd unrhyw beth yn y ZIL yn cael ei ddarllen, ei grwpio'n TXGs, ei ymrwymo i'r prif storfa, ac yna ei ddatgysylltu o'r ZIL yn ystod y broses fewnforio.
Gelwir un o'r dosbarthiadau cynorthwywyr vdev yn LOG neu SLOG, sef dyfais eilaidd LOG. Mae ganddo un pwrpas - darparu vdev ar wahân, ac yn llawer cyflymach yn ddelfrydol, sy'n gwrthsefyll ysgrifennu i storio'r ZIL, yn lle storio'r ZIL ar y brif storfa vdev. Mae'r ZIL ei hun yn ymddwyn yr un peth ni waeth ble mae'n cael ei storio, ond os oes gan y LOG vdev berfformiad ysgrifennu uchel iawn, bydd ysgrifennu cydamserol yn gyflymach.
Nid yw ychwanegu vdev gyda LOG i'r pwll yn gweithio ni all gwella perfformiad ysgrifennu asyncronaidd - hyd yn oed os ydych chi'n gorfodi'r holl ysgrifennu i ZIL gyda zfs set sync=always, byddant yn dal i fod yn gysylltiedig â'r prif storfa yn TXG yn yr un modd ac ar yr un cyflymder â heb y log. Yr unig welliant perfformiad uniongyrchol yw hwyrni ysgrifennu cydamserol (oherwydd bod log cyflymach yn cyflymu gweithrediadau). sync).
Fodd bynnag, mewn amgylchedd sydd eisoes yn gofyn am lawer o ysgrifennu cydamserol, gall vdev LOG gyflymu ysgrifennu asyncronaidd a darlleniadau heb eu storio yn anuniongyrchol. Mae dadlwytho cofnodion ZIL i LOG vdev ar wahân yn golygu llai o gynnen i IOPS ar storfa gynradd, sy'n gwella perfformiad pob darlleniad ac ysgrifennu i ryw raddau.
Cipluniau
Mae'r mecanwaith copi-ar-ysgrifennu hefyd yn sylfaen angenrheidiol ar gyfer cipluniau atomig ZFS a dyblygu cynyddrannol asyncronaidd. Mae gan y system ffeiliau weithredol goeden pwyntydd sy'n nodi'r holl gofnodion â data cyfredol - pan fyddwch chi'n cymryd ciplun, rydych chi'n gwneud copi o'r goeden pwyntydd hon.
Pan fydd cofnod yn cael ei drosysgrifo ar y system ffeiliau weithredol, mae ZFS yn ysgrifennu'r fersiwn bloc newydd yn gyntaf i ofod nas defnyddiwyd. Yna mae'n datgysylltu'r hen fersiwn o'r bloc o'r system ffeiliau gyfredol. Ond os yw rhyw gipolwg yn cyfeirio at yr hen floc, mae'n dal heb ei newid. Ni fydd yr hen floc mewn gwirionedd yn cael ei adfer fel gofod rhydd nes bod yr holl gipluniau sy'n cyfeirio at y bloc hwn yn cael eu dinistrio!
Dyblygiad
Fy Llyfrgell Stêm yn 2015 oedd 158 GiB ac roedd yn cynnwys 126 o ffeiliau. Mae hyn yn eithaf agos at y sefyllfa orau ar gyfer rsync - roedd atgynhyrchu ZFS dros y rhwydwaith "yn unig" 927% yn gyflymach.
Ar yr un rhwydwaith, mae ailadrodd un ffeil delwedd peiriant rhithwir 40GB Windows 7 yn stori gwbl wahanol. Mae dyblygu ZFS 289 gwaith yn gyflymach na rsync - neu "dim ond" 161 gwaith yn gyflymach os ydych chi'n ddigon craff i alw rsync gyda --inplace.
Pan fydd delwedd VM wedi'i graddio, mae rsync yn pennu graddfa ag ef. 1,9 Nid yw TiB mor fawr â hynny ar gyfer delwedd VM fodern - ond mae'n ddigon mawr bod atgynhyrchu ZFS 1148 gwaith yn gyflymach na rsync, hyd yn oed gyda dadl --inplace rsync
Unwaith y byddwch yn deall sut mae cipluniau'n gweithio, dylai fod yn hawdd deall hanfod atgynhyrchu. Gan mai dim ond coeden o awgrymiadau i gofnodion yw ciplun, mae'n dilyn os gwnawn hynny zfs send cipolwg, yna rydym yn anfon y goeden hon a'r holl gofnodion sy'n gysylltiedig â hi. Pan fyddwn yn anfon hwn zfs send в zfs receive ar y targed, mae'n ysgrifennu cynnwys gwirioneddol y bloc a'r goeden awgrymiadau sy'n cyfeirio at y blociau i'r set ddata darged.
Mae pethau hyd yn oed yn fwy diddorol ar yr ail zfs send. Bellach mae gennym ddwy system, pob un yn cynnwys poolname/datasetname@1, a byddwch yn cymryd cipolwg newydd poolname/datasetname@2. Felly, yn y pwll gwreiddiol sydd gennych datasetname@1 и datasetname@2, ac yn y pwll targed hyd yn hyn dim ond y ciplun cyntaf datasetname@1.
Gan fod gennym giplun cyffredin rhwng y ffynhonnell a'r targed datasetname@1, gallwn ei wneud cynyddrannol zfs send Dros e. Pan ddywedwn wrth y system zfs send -i poolname/datasetname@1 poolname/datasetname@2, mae'n cymharu dwy goeden pwyntydd. Unrhyw awgrymiadau sy'n bodoli yn unig @2, yn amlwg yn cyfeirio at flociau newydd - felly mae angen cynnwys y blociau hyn.
Ar system bell, prosesu cynyddrannol send yr un mor syml. Yn gyntaf rydym yn ysgrifennu'r holl gofnodion newydd sydd wedi'u cynnwys yn y ffrwd send, ac yna ychwanegu awgrymiadau at y blociau hynny. Voila, mae gennym ni @2 yn y system newydd!
Mae atgynhyrchu cynyddrannol asyncronaidd ZFS yn welliant enfawr o gymharu â dulliau cynharach nad ydynt yn seiliedig ar giplun fel rsync. Yn y ddau achos, dim ond data wedi'i newid sy'n cael ei drosglwyddo - ond rhaid rsync yn gyntaf darllen o'r ddisg yr holl ddata ar y ddwy ochr i wirio'r swm a'i gymharu. Mewn cyferbyniad, nid yw dyblygu ZFS yn darllen dim ond coed pwyntydd - ac unrhyw flociau nad ydynt yn bresennol yn y ciplun a rennir.
Cywasgu adeiledig
Mae'r mecanwaith copi-ar-ysgrifennu hefyd yn symleiddio'r system cywasgu mewnol. Mewn system ffeiliau draddodiadol, mae cywasgu yn broblematig - mae'r hen fersiwn a'r fersiwn newydd o'r data wedi'u haddasu yn byw yn yr un gofod.
Os ydym yn ystyried darn o ddata yng nghanol ffeil sy'n dechrau bywyd fel megabeit o sero o 0x00000000 ac yn y blaen, mae'n hawdd iawn ei gywasgu i un sector ar ddisg. Ond beth sy'n digwydd os byddwn yn disodli'r megabeit hwnnw o sero gyda megabeit o ddata anghywasgadwy fel JPEG neu swn ffug-hap? Yn annisgwyl, bydd y megabeit hwn o ddata yn gofyn am nid un, ond 256 4 sector KiB, ac yn y lle hwn ar y ddisg dim ond un sector sydd wedi'i gadw.
Nid oes gan ZFS y broblem hon, gan fod cofnodion wedi'u haddasu bob amser yn cael eu hysgrifennu i ofod nas defnyddiwyd - dim ond un sector 4 KiB y mae'r bloc gwreiddiol yn ei feddiannu, a bydd y cofnod newydd yn meddiannu 256, ond nid yw hyn yn broblem - darn a addaswyd yn ddiweddar o'r " byddai canol" y ffeil yn cael ei ysgrifennu i ofod nas defnyddiwyd p'un a yw ei maint wedi newid ai peidio, felly i ZFS mae hon yn sefyllfa eithaf rheolaidd.
Mae cywasgu ZFS brodorol wedi'i analluogi yn ddiofyn, ac mae'r system yn cynnig algorithmau y gellir eu plygio - ar hyn o bryd LZ4, gzip (1-9), LZJB, a ZLE.
- LZ4 yn algorithm ffrydio sy'n cynnig cywasgu a datgywasgiad hynod o gyflym a manteision perfformiad ar gyfer y rhan fwyaf o achosion defnydd - hyd yn oed ar CPUs eithaf araf.
- gzip yn algorithm hybarch y mae holl ddefnyddwyr Unix yn ei wybod ac yn ei garu. Gellir ei weithredu gyda lefelau cywasgu 1-9, gyda chymhareb cywasgu a defnydd CPU yn cynyddu wrth iddo nesáu at lefel 9. Mae'r algorithm yn addas iawn ar gyfer pob achos defnydd testun (neu achosion eraill cywasgadwy iawn), ond fel arall yn aml yn achosi problemau CPU - defnyddiwch ef gyda gofal, yn enwedig ar lefelau uwch.
- LZJB yw'r algorithm gwreiddiol yn ZFS. Mae'n anghymeradwy ac ni ddylid ei ddefnyddio mwyach, mae'r LZ4 yn rhagori arno ym mhob ffordd.
- DRWG - amgodio lefel sero, amgodio Lefel Sero. Nid yw'n cyffwrdd â data arferol o gwbl, ond mae'n cywasgu dilyniannau mawr o sero. Yn ddefnyddiol ar gyfer setiau data cwbl anghywasgadwy (fel JPEG, MP4, neu fformatau eraill sydd eisoes wedi'u cywasgu) gan ei fod yn anwybyddu data anghywasgadwy ond yn cywasgu gofod nas defnyddiwyd yn y cofnodion canlyniadol.
Rydym yn argymell cywasgu LZ4 ar gyfer bron pob achos defnydd; mae'r gosb perfformiad wrth ddod ar draws data anghywasgadwy yn fach iawn, a twf mae perfformiad ar gyfer data nodweddiadol yn arwyddocaol. Copïo delwedd peiriant rhithwir ar gyfer gosodiad newydd o system weithredu Windows (OS wedi'i osod yn ffres, dim data y tu mewn eto) gyda compression=lz4 pasio 27% yn gyflymach na gyda compression=noneYn .
ARC - storfa amnewid addasol
ZFS yw'r unig system ffeiliau fodern y gwyddom amdani sy'n defnyddio ei mecanwaith caching darllen ei hun, yn hytrach na dibynnu ar storfa tudalen y system weithredu i storio copïau o flociau a ddarllenwyd yn ddiweddar yn RAM.
Er nad yw'r storfa frodorol heb ei broblemau - ni all ZFS ymateb i geisiadau dyrannu cof newydd mor gyflym â'r cnewyllyn, felly yr her newydd malloc() efallai y bydd dyraniad cof yn methu os oes angen yr RAM y mae ARC yn ei ddefnyddio ar hyn o bryd. Ond mae yna resymau da dros ddefnyddio'ch storfa eich hun, am y tro o leiaf.
Mae'r holl systemau gweithredu modern hysbys, gan gynnwys MacOS, Windows, Linux a BSD, yn defnyddio'r algorithm LRU (Defnyddiwyd Lleiaf Yn Ddiweddar) i weithredu'r storfa dudalen. Mae hwn yn algorithm cyntefig sy'n gwthio'r bloc cached "i fyny'r ciw" ar ôl pob darlleniad, ac yn gwthio'r blociau "i lawr y ciw" yn ôl yr angen i ychwanegu methiannau cache newydd (blociau y dylid bod wedi'u darllen o ddisg, nid o'r celc) i fyny.
Mae'r algorithm fel arfer yn gweithio'n iawn, ond ar systemau gyda setiau data gweithio mawr, mae LRU yn arwain yn hawdd at ddyrnu - gan droi allan blociau sydd eu hangen yn aml i wneud lle i flociau na fydd byth yn cael eu darllen o'r storfa eto.
yn algorithm llawer llai naïf y gellir ei ystyried fel storfa "pwysoledig". Bob tro mae bloc wedi'i storio yn cael ei ddarllen, mae'n mynd ychydig yn "drymach" ac yn anoddach ei droi allan - a hyd yn oed ar ôl dadfeddiannu bloc tracio o fewn cyfnod penodol o amser. Bydd bloc sydd wedi'i droi allan ond sydd angen ei ddarllen yn ôl i'r storfa hefyd yn dod yn "drymach".
Canlyniad hyn oll yw storfa gyda chymhareb daro llawer uwch, y gymhareb rhwng trawiadau cache (darllen a berfformiwyd o'r storfa) a methiannau cache (yn darllen o ddisg). Mae hwn yn ystadegyn hynod o bwysig - nid yn unig y mae'r trawiadau celc eu hunain yn cael eu cyflwyno i orchmynion maint yn gyflymach, gall methiannau cache gael eu cyflwyno'n gyflymach hefyd, oherwydd po fwyaf o drawiadau celc sydd, y lleiaf o geisiadau disg cydamserol a'r lleiaf yw'r hwyrni ar gyfer y methiannau hynny sy'n weddill rhaid ei weini gyda disg.
Casgliad
Ar ôl dysgu semanteg sylfaenol ZFS - sut mae copi-ar-ysgrifennu yn gweithio, yn ogystal â'r perthnasoedd rhwng pyllau storio, dyfeisiau rhithwir, blociau, sectorau a ffeiliau - rydym yn barod i drafod perfformiad y byd go iawn gyda rhifau real.
Yn y rhan nesaf, byddwn yn edrych ar berfformiad gwirioneddol pyllau gyda vdevs a RAIDz wedi'u hadlewyrchu, yn erbyn ei gilydd, a hefyd yn erbyn topolegau RAID cnewyllyn Linux traddodiadol yr ydym wedi'u harchwilio. .
Ar y dechrau, roeddem am gwmpasu'r pethau sylfaenol yn unig - topolegau ZFS eu hunain - ond ar ôl hynny o'r fath gadewch i ni baratoi i siarad am osod a thiwnio mwy datblygedig o ZFS, gan gynnwys defnyddio mathau vdev ategol fel L2ARC, SLOG a Dyraniad Arbennig.
Ffynhonnell: hab.com