Ĉi-printempe ni jam diskutis kelkajn enkondukajn temojn, ekzemple, и . En la dua el ili, ni eĉ promesis daŭrigi studi la agadon de diversaj plurdiskaj topologioj en ZFS. Ĉi tiu estas la venontgeneracia dosiersistemo, kiu nun estas efektivigita ĉie: de por .
Nu, hodiaŭ estas la plej bona tago por konatiĝi kun ZFS, scivolaj legantoj. Nur sciu, ke laŭ la humila opinio de la programisto de OpenZFS Matt Ahrens, "ĝi estas vere malfacila."
Sed antaŭ ol ni atingos la nombrojn - kaj ili faros, mi promesas - por ĉiuj opcioj por ok-diska ZFS-agordo, ni devas paroli pri kiom Ĝenerale, ZFS stokas datumojn sur disko.
Zpool, vdev kaj aparato
Ĉi tiu plena naĝejdiagramo inkluzivas tri helpajn vdevs, unu el ĉiu klaso, kaj kvar por RAIDz2
Kutime ne ekzistas kialo por krei aron da miskongruaj vdev-tipoj kaj grandecoj - sed nenio malhelpas vin fari tion se vi volas.
Por vere kompreni la ZFS-dosiersistemon, vi devas atente rigardi ĝian realan strukturon. Unue, ZFS unuigas la tradiciajn nivelojn de volumo kaj dosiersistemo-administrado. Due, ĝi uzas transakcian kopion-sur-skriban mekanismon. Ĉi tiuj trajtoj signifas, ke la sistemo estas strukture tre malsama de konvenciaj dosiersistemoj kaj RAID-aroj. La unua aro de bazaj konstrubriketoj por kompreni estas la stokado (zpool), virtuala aparato (vdev), kaj reala aparato (aparato).
zoko
La zpool-stokado estas la plej supra ZFS-strukturo. Ĉiu naĝejo enhavas unu aŭ plurajn virtualajn aparatojn. Siavice, ĉiu el ili enhavas unu aŭ plurajn realajn aparatojn (aparaton). Virtualaj naĝejoj estas memstaraj blokoj. Unu fizika komputilo povas enhavi du aŭ pli da apartaj naĝejoj, sed ĉiu estas tute sendependa de la aliaj. Naĝejoj ne povas kunhavi virtualajn aparatojn.
La redundo de ZFS estas sur la virtuala aparato-nivelo, ne sur la naĝejo. Estas absolute neniu redundo ĉe la naĝejo - se iu disko vdev aŭ speciala vdev estas perdita, tiam la tuta naĝejo estas perdita kune kun ĝi.
Modernaj stokaj naĝejoj povas postvivi la perdon de kaŝmemoro aŭ virtuala aparato-protokolo - kvankam ili povas perdi malgrandan kvanton da malpuraj datumoj se ili perdas la vdev-registron dum elektropaneo aŭ sistemkraŝo.
Estas ofta miskompreniĝo ke ZFS "datumstrioj" estas skribitaj tra la tuta naĝejo. Ĉi tio ne estas vera. Zpool tute ne estas amuza RAID0, ĝi estas sufiĉe amuza kun kompleksa varia distribua mekanismo.
Plejparte, la enskriboj estas distribuitaj inter la disponeblaj virtualaj aparatoj laŭ la disponebla libera spaco, do en teorio ili ĉiuj estos plenigitaj samtempe. En pli postaj versioj de ZFS, la nuna vdev-uzo (utiligo) estas konsiderata - se unu virtuala aparato estas signife pli okupata ol alia (ekzemple, pro legado de ŝarĝo), ĝi estos provizore preterlasita por skribado, malgraŭ havi la plej altan liberan. spacproporcio.
La utiliga detekta mekanismo enkonstruita en modernaj ZFS-skriba asignometodoj povas redukti latencia kaj pliigi trairon dum periodoj de nekutime alta ŝarĝo - sed ĝi ne faras carte blanche pri nevola miksado de malrapidaj HDD-oj kaj rapidaj SSD-oj en unu naĝejo. Tia neegala naĝejo ankoraŭ funkcios kun la rapideco de la plej malrapida aparato, tio estas, kvazaŭ ĝi estus tute kunmetita de tiaj aparatoj.
vdev
Ĉiu stokado konsistas el unu aŭ pluraj virtualaj aparatoj (virtuala aparato, vdev). Siavice, ĉiu vdev enhavas unu aŭ plurajn realajn aparatojn. Plej multaj virtualaj aparatoj estas uzataj por simpla datumstokado, sed ekzistas pluraj vdev-helpaj klasoj, inkluzive de CACHE, LOG, kaj SPECIAL. Ĉiu el ĉi tiuj vdev-tipoj povas havi unu el kvin topologioj: ununura aparato (unu-aparato), RAIDz1, RAIDz2, RAIDz3, aŭ spegulo (spegulo).
RAIDz1, RAIDz2 kaj RAIDz3 estas specialaj varioj de tio, kion la malnovtempuloj nomus duobla (diagonala) egaleco RAID. 1, 2 kaj 3 rilatas al kiom da egalecblokoj estas asignitaj por ĉiu datenstrio. Anstataŭ apartaj diskoj por egaleco, RAIDz virtualaj aparatoj distribuas tiun egalecon duonegale tra diskoj. RAIDz-aro povas perdi tiom da diskoj kiom ĝi havas egalecajn blokojn; se ĝi perdos alian, ĝi kraŝos kaj kunportos la stokejon.
En spegulitaj virtualaj aparatoj (spegula vdev), ĉiu bloko estas stokita sur ĉiu aparato en la vdev. Kvankam du-larĝaj speguloj estas la plej oftaj, ajna arbitra nombro da aparatoj povas esti en spegulo - triopoj ofte estas uzataj en grandaj instalaĵoj por plibonigita legado kaj misfunkciado. Vdev-spegulo povas postvivi ajnan fiaskon tiel longe kiel almenaŭ unu aparato en la vdev daŭre funkcias.
Unuopaj vdevs estas esence danĝeraj. Tia virtuala aparato ne postvivos eĉ unu fiaskon - kaj se uzata kiel stokado aŭ speciala vdev, tiam ĝia fiasko kondukos al la detruo de la tuta naĝejo. Estu tre, tre singarda ĉi tie.
CACHE, LOG, kaj SPECIALA VAoj povas esti kreitaj uzante iun el la supraj topologioj - sed memoru ke la perdo de SPECIALA VA signifas la perdon de la naĝejo, do redunda topologio estas tre rekomendinda.
artefakto
Ĉi tio verŝajne estas la plej facila termino por kompreni en ZFS - ĝi estas laŭvorte bloka hazarda aliro aparato. Memoru, ke virtualaj aparatoj konsistas el individuaj aparatoj, dum naĝejo konsistas el virtualaj aparatoj.
Diskoj - aŭ magnetaj aŭ solidaj - estas la plej oftaj blokaparatoj kiuj estas utiligitaj kiel la konstrubriketoj de vdev. Tamen, ajna aparato kun priskribilo en /dev faros, do tutaj aparataj RAID-tabeloj povas esti uzataj kiel apartaj aparatoj.
Simpla kruda dosiero estas unu el la plej gravaj alternativaj blokaj aparatoj, el kiuj vdev povas esti konstruita. Testaj naĝejoj de estas tre oportuna maniero kontroli naĝejojn komandojn kaj vidi kiom da spaco estas disponebla en naĝejo aŭ virtuala aparato de donita topologio.
Vi povas krei testan naĝejon el malabundaj dosieroj en nur kelkaj sekundoj - sed ne forgesu forigi la tutan naĝejon kaj ĝiajn komponantojn poste
Ni diru, ke vi volas meti servilon sur ok diskojn kaj planas uzi 10 TB-diskojn (~9300 GiB) - sed vi ne certas, kiu topologio plej taŭgas por viaj bezonoj. En la supra ekzemplo, ni konstruas testan grupon el malabundaj dosieroj en sekundoj - kaj nun ni scias, ke RAIDz2 vdev de ok 10 TB-diskoj provizas 50 TiB de uzebla kapablo.
Alia speciala klaso de aparatoj estas SPARE (rezervo). Varm-interŝanĝaj aparatoj, male al regulaj aparatoj, apartenas al la tuta naĝejo, kaj ne al ununura virtuala aparato. Se vdev en la naĝejo malsukcesas kaj rezerva aparato estas konektita al la naĝejo kaj disponebla, tiam ĝi aŭtomate aliĝos al la tuŝita vdev.
Post konekto al la tuŝita vdev, la rezerva aparato komencas ricevi kopiojn aŭ rekonstruojn de la datumoj kiuj devus esti sur la mankanta aparato. En tradicia RAID tio estas nomita rekonstruado, dum en ZFS ĝi estas nomita resilvering.
Gravas noti, ke rezervaj aparatoj ne konstante anstataŭigas malsukcesajn aparatojn. Ĉi tio estas nur provizora anstataŭaĵo por redukti la kvanton da tempo, ke vdev estas degradita. Post kiam la administranto anstataŭigas la malsukcesan vdev, redundo estas restarigita al tiu permanenta aparato, kaj SPARE estas malkonektita de la vdev kaj revenis por funkcii kiel rezerva por la tuta naĝejo.
Datumoj, blokoj kaj sektoroj
La sekva aro de konstrubriketoj por kompreni en nia ZFS-vojaĝo temas malpli pri la aparataro kaj pli pri kiel la datumoj mem estas organizitaj kaj stokitaj. Ni preterlasas kelkajn nivelojn ĉi tie - kiel metaslab - por ne malordigi la detalojn konservante komprenon de la ĝenerala strukturo.
Datenaro (datumaro)
Kiam ni unue kreas datumaron, ĝi montras la tutan disponeblan naĝejon. Poste ni fiksas la kvoton - kaj ŝanĝas la muntan punkton. Magio!
Zvol plejparte estas nur datumaro senigita de sia dosiersistemtavolo, kiun ni ĉi tie anstataŭigas per tute normala dosiersistemo ext4.
ZFS-datumaro estas proksimume la sama kiel norma muntita dosiersistemo. Kiel regula dosiersistemo, unuavide ĝi aspektas kiel "nur alia dosierujo". Sed same kiel regulaj munteblaj dosiersistemoj, ĉiu ZFS-datumaro havas sian propran aron de bazaj propraĵoj.
Antaŭ ĉio, datumaro povas havi asignitan kvoton. Se agordita zfs set quota=100G poolname/datasetname, tiam vi ne povos skribi al la muntita dosierujo /poolname/datasetname pli ol 100 GiB.
Rimarku la ĉeeston - kaj foreston - de oblikvoj komence de ĉiu linio? Ĉiu datumaro havas sian propran lokon en kaj la ZFS-hierarkio kaj la sistema munta hierarkio. Ne estas gvida oblikvo en la ZFS-hierarkio - vi komencas per la naĝejo-nomo kaj poste la vojo de unu datumaro al la sekva. Ekzemple, pool/parent/child por datumaro nomita child sub la gepatra datumaro parent en naĝejo kun krea nomo pool.
Defaŭlte, la munta punkto de la datumaro estos ekvivalenta al sia nomo en la ZFS-hierarkio, kun gvida oblikvo - la naĝejo nomita pool muntita kiel /pool, datumaro parent muntita en /pool/parent, kaj la infana datumaro child muntita en /pool/parent/child. Tamen, la sistema munta punkto de la datumaro povas esti ŝanĝita.
Se ni precizigas zfs set mountpoint=/lol pool/parent/child, tiam la datumaro pool/parent/child muntita sur la sistemo kiel /lol.
Krom datumaroj, ni menciu volumojn (zvols). Volumo estas proksimume sama kiel datumaro, krom ke ĝi fakte ne havas dosiersistemon—ĝi estas nur bloka aparato. Vi povas, ekzemple, krei zvol Kun nomo mypool/myzvol, tiam formatu ĝin per ext4-dosiersistemo, kaj poste muntu tiun dosiersistemon - vi nun havas ext4-dosiersistemon, sed kun ĉiuj sekurecaj funkcioj de ZFS! Ĉi tio povas ŝajni stulta sur ununura maŝino, sed havas multe pli da senco kiel backend kiam eksportado de iSCSI-aparato.
Blokoj
La dosiero estas reprezentita per unu aŭ pluraj blokoj. Ĉiu bloko estas stokita sur unu virtuala aparato. La blokgrandeco kutime egalas al la parametro rekordgrandeco, sed povas esti reduktita al 2^movose ĝi enhavas metadatenojn aŭ malgrandan dosieron.
Ni vere vere ne ŝercante pri la grandega agado-puno se vi starigas tro malgrandan movon
En ZFS-naĝejo, ĉiuj datumoj, inkluzive de metadatenoj, estas stokitaj en blokoj. La maksimuma blokgrandeco por ĉiu datumaro estas difinita en la posedaĵo recordsize (rekorda grandeco). La rekorda grandeco povas esti ŝanĝita, sed ĉi tio ne ŝanĝos la grandecon aŭ lokon de iuj blokoj kiuj jam estis skribitaj al la datumaro - ĝi nur influas novajn blokojn kiam ili estas skribitaj.
Krom se alie specifita, la nuna defaŭlta rekorda grandeco estas 128 KiB. Ĝi estas speco de delikata komerco, kie agado ne estas perfekta, sed ĝi ankaŭ ne estas terura en la plej multaj kazoj. Recordsize povas esti agordita al ajna valoro de 4K ĝis 1M (kun altnivelaj agordoj recordsize vi povas instali eĉ pli, sed ĉi tio malofte estas bona ideo).
Ajna bloko rilatas al la datumoj de nur unu dosiero - vi ne povas ŝtopi du malsamajn dosierojn en unu blokon. Ĉiu dosiero konsistas el unu aŭ pluraj blokoj, depende de la grandeco. Se la dosiergrandeco estas pli malgranda ol la rekorda grandeco, ĝi estos konservita en pli malgranda blokgrandeco - ekzemple, bloko kun 2 KiB-dosiero okupos nur unu 4 KiB-sektoron sur la disko.
Se la dosiero estas sufiĉe granda kaj postulas plurajn blokojn, tiam ĉiuj rekordoj kun ĉi tiu dosiero estos de grandeco recordsize - inkluzive de la lasta enskribo, kies ĉefa parto povas esti .
zvols ne havas posedaĵon recordsize — anstataŭe ili havas ekvivalentan econ volblocksize.
Sektoroj
La lasta, plej baza konstrubriketo estas la sektoro. Ĝi estas la plej malgranda fizika unuo, kiu povas esti skribita aŭ legita de la subesta aparato. Dum pluraj jardekoj, la plej multaj diskoj uzis 512-bajtajn sektorojn. Lastatempe, la plej multaj diskoj estas fiksitaj al 4 KiB-sektoroj, kaj kelkaj - precipe SSD-oj - havas 8 KiB-sektorojn aŭ eĉ pli.
La ZFS-sistemo havas posedaĵon, kiu permesas vin mane agordi la sektorgrandecon. Ĉi tiu posedaĵo ashift. Iom konfuze, ashift estas potenco de du. Ekzemple, ashift=9 signifas sektorgrandecon de 2^9, aŭ 512 bajtoj.
ZFS demandas la operaciumon por detalaj informoj pri ĉiu bloka aparato kiam ĝi estas aldonita al nova vdev, kaj teorie aŭtomate instalas ashift konvene surbaze de tiu informo. Bedaŭrinde, multaj diskoj kuŝas pri sia sektorgrandeco por konservi kongruon kun Windows XP (kiu ne povis kompreni diskojn kun aliaj sektorgrandoj).
Ĉi tio signifas, ke ZFS-administranto estas forte konsilita scii la realan sektorgrandecon de siaj aparatoj kaj permane agordi ashift. Se ashift estas agordita tro malalta, tiam la nombro da leg-/skribaj operacioj pliiĝas astronomie. Do, skribi 512-bajtajn "sektorojn" en veran 4 KiB-sektoron signifas devi skribi la unuan "sektoron", poste legi la 4 KiB-sektoron, modifi ĝin per dua 512-bajta "sektoro", reskribi ĝin al la nova. 4 KiB-sektoro, kaj tiel plu por ĉiu eniro.
En la reala mondo, tia puno trafas Samsung EVO-SSD-ojn, por kiuj ashift=13, sed ĉi tiuj SSD-oj kuŝas pri sia sektora grandeco, kaj tial la defaŭlto estas agordita ashift=9. Se sperta sistemadministranto ne ŝanĝas ĉi tiun agordon, tiam ĉi tiu SSD funkcias pli malrapida konvencia magneta HDD.
Por komparo, por tro granda grandeco ashift estas praktike neniu puno. Ne ekzistas reala agado-puno, kaj la pliiĝo en neuzata spaco estas infinitezima (aŭ nulo kun kunpremado ebligita). Tial ni forte rekomendas, ke eĉ tiuj diskoj, kiuj uzas 512-bajtajn sektorojn, instalu ashift=12 aŭ eĉ ashift=13por alfronti la estontecon kun konfido.
Posedaĵo ashift estas agordita por ĉiu vdev virtuala aparato, kaj ne por la naĝejo, kiel multaj erare pensas - kaj ne ŝanĝiĝas post instalado. Se vi hazarde trafis ashift kiam vi aldonas novan vdev al naĝejo, vi nerehaveble poluis tiun naĝejon per malalta rendimenta aparato kaj kutime ne estas alia elekto sed detrui la naĝejon kaj rekomenci. Eĉ forigi vdev ne savos vin de rompita agordo ashift!
Kopi-sur-skriba mekanismo
Se regula dosiersistemo bezonas anstataŭigi datumojn, ĝi ŝanĝas ĉiun blokon kie ĝi estas
Kopi-sur-skriba dosiersistemo skribas novan blokversion kaj poste malŝlosas la malnovan version
En abstraktaĵo, se ni ignoras la realan fizikan lokon de la blokoj, tiam nia "datumkometo" estas simpligita al "datumvermo" kiu moviĝas de maldekstre dekstren tra la mapo de disponebla spaco.
Nun ni povas akiri bonan ideon pri kiel funkcias kopi-sur-skribaj momentfotoj - ĉiu bloko povas esti posedata de pluraj momentfotoj, kaj daŭros ĝis ĉiuj rilataj momentfotoj estas detruitaj.
La mekanismo de Kopio sur Skribo (CoW) estas la fundamenta bazo de tio, kio faras ZFS tia mirinda sistemo. La baza koncepto estas simpla - se vi petas al tradicia dosiersistemo ŝanĝi dosieron, ĝi faros ĝuste tion, kion vi petis. Se vi petas al kopio-sur-skriba dosiersistemo fari la samon, ĝi diros "bone" sed mensogos al vi.
Anstataŭe, kopio-sur-skriba dosiersistemo skribas novan version de la modifita bloko kaj tiam ĝisdatigas la metadatenojn de la dosiero por malligi la malnovan blokon kaj asocii la novan blokon, kiun vi ĵus skribis al ĝi.
Dekroĉi la malnovan blokon kaj ligi la novan estas farita en unu operacio, do ĝi ne povas esti interrompita - se vi malŝaltas post tio okazas, vi havas novan version de la dosiero, kaj se vi malŝaltas frue, vi havas la malnovan version. . Ĉiukaze, ne estos konfliktoj en la dosiersistemo.
Kopiado-sur-skribi en ZFS okazas ne nur ĉe la dosiersistemo-nivelo, sed ankaŭ ĉe la diskadministra nivelo. Ĉi tio signifas, ke ZFS ne estas tuŝita de blanka spaco () - fenomeno kiam la strio havis tempon nur parte registri antaŭ ol la sistemo kraŝis, kun tabelo damaĝo post rekomenco. Ĉi tie la strio estas skribita atome, vdev estas ĉiam sinsekva, kaj .
ZIL: ZFS-intencprotokolo
La ZFS-sistemo traktas sinkronajn skribojn en speciala maniero - ĝi provizore sed tuj konservas ilin en ZIL antaŭ ol skribi ilin konstante poste kune kun nesinkronaj skribaĵoj.
Tipe, datumoj skribitaj al ZIL neniam estas legitaj denove. Sed ĝi eblas post sistema kraŝo
SLOG, aŭ malĉefa LOG-aparato, estas nur speciala - kaj prefere tre rapida - vdev, kie la ZIL povas esti stokita aparte de la ĉefa stokado.
Post kraŝo, ĉiuj malpuraj datumoj en ZIL estas reluditaj - ĉi-kaze, ZIL estas sur SLOG, do ĝi estas reludata de tie
Estas du ĉefaj kategorioj de skribaj operacioj - sinkrona (sinkrona) kaj nesinkrona (sensinkrona). Por la plej multaj laborŝarĝoj, la vasta plimulto de skribaĵoj estas nesinkronaj - la dosiersistemo permesas ilin esti agregataj kaj eldonitaj en aroj, reduktante fragmentiĝon kaj multe pliigante trairon.
Sinkronigitaj registradoj estas tute alia afero. Kiam aplikaĵo petas sinkronan skribon, ĝi diras al la dosiersistemo: "Vi devas transigi ĉi tion al nevolatila memoro. nunĝis tiam, mi povas fari nenion alian." Tial, sinkronaj skriboj devus esti faritaj al disko tuj—kaj se tio pliigas fragmentiĝon aŭ reduktas trafluon, tiam tiel estu.
ZFS pritraktas sinkronajn skribojn alimaniere ol regulaj dosiersistemoj—anstataŭ tuj transigi ilin al regula stokado, ZFS transdonas ilin al speciala stokareo nomita la ZFS Intent Log, aŭ ZIL. La lertaĵo estas ke ĉi tiuj rekordoj ankaŭ resti en memoro, estante aldonita kune kun normalaj nesinkronaj skribpetoj, por esti poste fluitaj al stokado kiel perfekte normalaj TXGs (Transakcio-Grupoj).
En normala funkciado, la ZIL estas skribita al kaj neniam legita denove. Kiam, post kelkaj momentoj, la rekordoj de la ZIL estas kompromititaj al la ĉefa stokado en ordinaraj TXGs de RAM, ili estas dekroĉitaj de la ZIL. La nura tempo kiam io estas legita de la ZIL estas kiam la naĝejo estas importita.
Se ZFS malsukcesas - mastruma sistemo kraŝo aŭ elektropaneo - dum estas datumoj en la ZIL, tiuj datumoj estos legitaj dum la venonta naĝejo importo (ekzemple, dum rekomenco de la krizsistemo). Io ajn en la ZIL estos legita, grupigita en TXG-ojn, kompromitita al la ĉefa stokado, kaj tiam dekroĉita de la ZIL dum la importa procezo.
Unu el la vdev-helpklasoj nomiĝas LOG aŭ SLOG, la malĉefa aparato de LOG. Ĝi havas unu celon - provizi la naĝejon per aparta, kaj prefere multe pli rapida, tre skriba imuna vdev por stoki la ZIL, anstataŭ stoki la ZIL en la ĉefa vdev-butiko. La ZIL mem kondutas same, negrave kie ĝi estas stokita, sed se la LOG-vdev havas tre altan skribefikecon, sinkronaj skriboj estos pli rapidaj.
Aldoni vdev kun LOG al la naĝejo ne funkcias ne povas plibonigu nesinkronan skriban rendimenton - eĉ se vi devigas ĉiujn skribojn al ZIL per zfs set sync=always, ili ankoraŭ estos ligitaj al la ĉefa stokado en TXG sammaniere kaj samrapide kiel sen la protokolo. La nura rekta agado-plibonigo estas la latenteco de sinkronaj skriboj (ĉar pli rapida protokolo plirapidigas operaciojn). sync).
Tamen, en medio kiu jam postulas multajn sinkronajn skribojn, vdev LOG povas nerekte akceli nesinkronajn skribojn kaj ne-kaŝmemorajn legadojn. Malŝarĝi ZIL-enskribojn al aparta vdev-LOGO signifas malpli da disputo por IOPS pri primara stokado, kio plibonigas la rendimenton de ĉiuj legadoj kaj skribaĵoj iagrade.
Momentfotoj
La kopio-sur-skriba mekanismo ankaŭ estas necesa fundamento por ZFS-atomaj momentfotoj kaj pliiga nesinkrona reproduktado. La aktiva dosiersistemo havas montril-arbon, kiu markas ĉiujn rekordojn kun aktualaj datumoj - kiam vi prenas momentfoton, vi simple faras kopion de ĉi tiu montril-arbo.
Kiam rekordo estas anstataŭita sur la aktiva dosiersistemo, ZFS unue skribas la novan blokversion al neuzata spaco. Ĝi tiam deprenas la malnovan version de la bloko de la nuna dosiersistemo. Sed se iu momentfoto rilatas al la malnova bloko, ĝi ankoraŭ restas senŝanĝa. La malnova bloko efektive ne estos restarigita kiel libera spaco ĝis ĉiuj momentfotoj referencantaj ĉi tiun blokon estos detruitaj!
reproduktado
Mia Steam-biblioteko en 2015 estis 158 GiB kaj inkludis 126 dosierojn. Ĉi tio estas sufiĉe proksima al la optimuma situacio por rsync - ZFS-reproduktado tra la reto estis "nur" 927% pli rapida.
En la sama reto, reprodukti ununuran bilddosieron de 40GB Vindozo 7 virtuala maŝina estas tute malsama rakonto. ZFS-reproduktado estas 289 fojojn pli rapida ol rsync - aŭ "nur" 161 fojojn pli rapida se vi estas sufiĉe inteligenta por voki rsync per --inplace.
Kiam VM-bildo estas skalita, rsync-problemoj skalas kun ĝi. 1,9 TiB ne estas tiom granda por moderna VM-bildo - sed ĝi estas sufiĉe granda, ke ZFS-reproduktado estas 1148 fojojn pli rapida ol rsync, eĉ kun la argumento --inplace de rsync.
Post kiam vi komprenas kiel funkcias momentfotoj, devus esti facile ekkompreni la esencon de reproduktado. Ĉar momentfoto estas nur arbo de montriloj al registroj, tio sekvas, se ni faros zfs send momentfoto, tiam ni sendas kaj ĉi tiun arbon kaj ĉiujn rekordojn asociitajn kun ĝi. Kiam ni sendas ĉi tion zfs send в zfs receive sur la celo, ĝi skribas kaj la realan enhavon de la bloko kaj la arbo de montriloj kiuj rilatas al la blokoj al la cela datumaro.
Aferoj fariĝas eĉ pli interesaj je la dua zfs send. Ni nun havas du sistemojn, ĉiu enhavanta poolname/datasetname@1, kaj vi prenas novan momentfoton poolname/datasetname@2. Tial, en la originala naĝejo vi havas datasetname@1 и datasetname@2, kaj en la cela naĝejo ĝis nun nur la unua momentfoto datasetname@1.
Ĉar ni havas komunan momentfoton inter la fonto kaj la celo datasetname@1, Ni povas fari ĝin pliiga zfs send super ĝi. Kiam ni diras al la sistemo zfs send -i poolname/datasetname@1 poolname/datasetname@2, ĝi komparas du montril arbojn. Ajnaj indikiloj, kiuj nur ekzistas en @2, evidente rilatas al novaj blokoj - do ni bezonas la enhavon de ĉi tiuj blokoj.
En fora sistemo, prilaborado de pliiga send same simple. Unue ni skribas ĉiujn novajn enskribojn inkluzivitajn en la fluo send, kaj tiam aldonu montrilojn al tiuj blokoj. Voila, ni havas @2 en la nova sistemo!
ZFS nesinkrona pliiga reproduktado estas grandega plibonigo super pli fruaj metodoj bazitaj en ne-momentfotoj kiel ekzemple rsync. En ambaŭ kazoj, nur ŝanĝitaj datumoj estas transdonitaj - sed rsync devas unue legi de la disko ĉiuj datumoj ambaŭflanke por kontroli la sumon kaj kompari ĝin. En kontrasto, ZFS-reproduktado legas nenion krom montril arboj - kaj iujn ajn blokojn kiuj ne ĉeestas en la komuna momentfoto.
Enkonstruita kunpremo
La kopio-sur-skriba mekanismo ankaŭ simpligas la enlinian kunpremadsistemon. En tradicia dosiersistemo, kunpremado estas problema - kaj la malnova versio kaj la nova versio de la modifitaj datumoj loĝas en la sama spaco.
Se ni konsideras pecon de datumoj en la mezo de dosiero, kiu komencas vivon kiel megabajto de nuloj de 0x00000000 kaj tiel plu, estas tre facile kunpremi ĝin al unu sektoro sur disko. Sed kio okazas se ni anstataŭigas tiun megabajton da nuloj per megabajto da nekunpremeblaj datumoj kiel JPEG aŭ pseŭdo-hazarda bruo? Neatendite, ĉi tiu megabajto da datumoj postulos ne unu, sed 256 4 KiB-sektorojn, kaj en ĉi tiu loko sur la disko nur unu sektoro estas rezervita.
ZFS ne havas ĉi tiun problemon, ĉar modifitaj rekordoj ĉiam estas skribitaj en neuzatan spacon - la origina bloko okupas nur unu 4 KiB-sektoron, kaj la nova rekordo okupos 256, sed tio ne estas problemo - lastatempe modifita fragmento de la " meza" de la dosiero estus skribita al neuzata spaco sendepende de ĉu ĝia grandeco ŝanĝiĝis aŭ ne, do por ZFS tio estas sufiĉe regula situacio.
Denaska ZFS-kunpremo estas malŝaltita defaŭlte, kaj la sistemo ofertas ŝtopeblajn algoritmojn—nuntempe LZ4, gzip (1-9), LZJB kaj ZLE.
- LZ4 estas fluanta algoritmo kiu ofertas ekstreme rapidan kunpremadon kaj malkunpremadon kaj rendimentajn avantaĝojn por plej multaj uzkazoj - eĉ sur sufiĉe malrapidaj CPUoj.
- GZIP estas respektinda algoritmo, kiun ĉiuj uzantoj de Unikso konas kaj amas. Ĝi povas esti efektivigita kun kunpremadniveloj 1-9, kun kunpremadproporcio kaj CPU-uzo pliiĝanta kiam ĝi alproksimiĝas al nivelo 9. La algoritmo estas bone konvenita por ĉiuj tekstoj (aŭ aliaj tre kunpremeblaj) uzkazoj, sed alie ofte kaŭzas CPU-problemojn - uzu ĝin. zorge, precipe ĉe pli altaj niveloj.
- LZJB estas la origina algoritmo en ZFS. Ĝi estas malrekomendita kaj ne plu estu uzata, la LZ4 ĉiel superas ĝin.
- ZLE - Nula-nivela kodado, Nula-nivela kodado. Ĝi tute ne tuŝas normalajn datumojn, sed kunpremas grandajn sekvencojn de nuloj. Utila por tute nekunpremeblaj datenoj (kiel JPEG, MP4 aŭ aliaj jam kunpremitaj formatoj) ĉar ĝi ignoras nekunpremeblajn datumojn sed kunpremas neuzatan spacon en la rezultaj rekordoj.
Ni rekomendas LZ4-kunpremadon por preskaŭ ĉiuj uzkazoj; la agado-puno kiam oni renkontas nekunpremeblajn datumojn estas tre malgranda, kaj kresko rendimento por tipaj datumoj estas signifa. Kopiado de virtuala maŝina bildo por nova instalo de la Vindoza operaciumo (ĵus instalita OS, ankoraŭ neniuj datumoj ene) per compression=lz4 pasis 27% pli rapide ol kun compression=noneen .
ARC - adapta anstataŭiga kaŝmemoro
ZFS estas la nura moderna dosiersistemo pri kiu ni konas, kiu uzas sian propran legan kaŝmemormekanismon, prefere ol fidi je la paĝa kaŝmemoro de la operaciumo por stoki kopiojn de lastatempe legitaj blokoj en RAM.
Kvankam la denaska kaŝmemoro ne estas sen problemoj - ZFS ne povas respondi al novaj memor-asignaj petoj same rapide kiel la kerno, do la nova defio malloc() pri memora atribuo povas malsukcesi se ĝi bezonas la RAM nuntempe okupitan de ARC. Sed estas bonaj kialoj por uzi vian propran kaŝmemoron, almenaŭ nuntempe.
Ĉiuj konataj modernaj operaciumoj, inkluzive de MacOS, Vindozo, Linukso kaj BSD, uzas la algoritmon LRU (Malplej Lastatempe Uzita) por efektivigi la paĝan kaŝmemoron. Ĉi tio estas primitiva algoritmo kiu puŝas la kaŝmemorblokon "supren la atendovico" post ĉiu legado, kaj puŝas la blokojn "malsupren la atendovico" laŭbezone por aldoni novajn kaŝmemoro-maltrafojn (blokoj kiuj devus estinti legitaj de disko, ne de la kaŝmemoro) supren.
La algoritmo kutime funkcias bone, sed ĉe sistemoj kun grandaj laboraj datumaroj, LRU facile kondukas al draŝo - forpelado de ofte bezonataj blokoj por fari lokon por blokoj kiuj neniam estos legitaj el la kaŝmemoro denove.
estas multe malpli naiva algoritmo kiu povas esti opiniita kiel "pezbalancita" kaŝmemoro. Ĉiufoje kiam oni legas kaŝmemoron blokon, ĝi fariĝas iom pli "peza" kaj pli malfacile forpelebla - kaj eĉ post elpelado de bloko spurita ene de certa tempodaŭro. Bloko kiu estis elmetita sed tiam devas esti relegita en la kaŝmemoron ankaŭ fariĝos "pli peza".
La fina rezulto de ĉio ĉi estas kaŝmemoro kun multe pli alta trafproporcio, la rilatumo inter kaŝmemortrafoj (legadoj faritaj de la kaŝmemoro) kaj kaŝmemoro mistrafitaj (legadoj de disko). Ĉi tio estas ege grava statistiko - ne nur la kaŝmemoro trafoj mem estas servataj ordoj de grandeco pli rapide, kaŝmemoro mistrafoj ankaŭ povas esti servitaj pli rapide, ĉar ju pli da kaŝmemoro trafoj, des malpli samtempaj diskpetoj kaj des pli malalta la latencia por tiuj ceteraj mistrafoj kiuj devas. esti servita kun disko.
konkludo
Post lerni la bazan semantikon de ZFS - kiel funkcias kopio-sur-skribado, kaj ankaŭ la rilatojn inter stokadejoj, virtualaj aparatoj, blokoj, sektoroj kaj dosieroj - ni pretas diskuti realan agadon kun realaj nombroj.
En la sekva parto, ni rigardos la realan agadon de naĝejoj kun spegulitaj vdevs kaj RAIDz, kontraŭ unu la alian, kaj ankaŭ kontraŭ la tradiciaj Linuksaj kernaj RAID-topologioj, kiujn ni esploris. .
Komence, ni volis kovri nur la bazaĵojn - la ZFS-topologiojn mem - sed poste tia ni preparu nin por paroli pri pli altnivela agordo kaj agordado de ZFS, inkluzive de la uzo de helpaj vdev-tipoj kiel L2ARC, SLOG kaj Speciala Asigno.
fonto: www.habr.com