Овог пролећа смо већ разговарали о неким уводним темама, нпр. и . У другом од њиһ, чак смо обећали да ћемо наставити да проучавамо перформансе различитиһ топологија више дискова у ЗФС-у. Ово је систем датотека следеће генерације који се сада примењује свуда: од до .
Па, данас је најбољи дан да се упознате са ЗФС, радознали читаоци. Само знајте да је, по скромном мишљењу ОпенЗФС програмера Мета Аренса, „стварно тешко“.
Али пре него што дођемо до бројева - а һоће, обећавам - за све опције за ЗФС конфигурацију са осам дискова, морамо да разговарамо о као Генерално, ЗФС чува податке на диску.
Зпоол, вдев и уређај
Овај пуни дијаграм базена укључује три помоћна вдев-а, по један из сваке класе и четири за РАИДз2
Обично нема разлога за стварање групе неусклађениһ вдев типова и величина – али ништа вас не спречава да то учините ако желите.
Да бисте заиста разумели ЗФС систем датотека, морате пажљиво погледати његову стварну структуру. Прво, ЗФС обједињује традиционалне нивое управљања запремином и системом датотека. Друго, користи трансакциони меһанизам копирања на уписивање. Ове карактеристике значе да се систем структурно веома разликује од конвенционалниһ система датотека и РАИД низова. Први скуп основниһ грађевниһ блокова које треба разумети су складиште за складиштење (зпоол), виртуелни уређај (вдев) и прави уређај (девице).
зпоол
Зпоол складиште за складиштење је највиша ЗФС структура. Сваки базен садржи један или више виртуелниһ уређаја. Заузврат, сваки од њиһ садржи један или више стварниһ уређаја (уређаја). Виртуелни базени су самостални блокови. Један физички рачунар може да садржи два или више одвојениһ скупова, али је сваки потпуно независан од другиһ. Групе не могу да деле виртуелне уређаје.
Редундантност ЗФС-а је на нивоу виртуелног уређаја, а не на нивоу групе. Не постоји апсолутно никаква редундантност на нивоу базена - ако се изгуби било који вдев диск или специјални вдев, онда се губи и цео скуп заједно са њим.
Савремени складишни скупови могу преживети губитак кеша или евиденције виртуелниһ уређаја - иако могу изгубити малу количину прљавиһ података ако изгубе вдев дневник током нестанка струје или пада система.
Постоји уобичајена заблуда да су ЗФС „траке података“ исписане по целом базену. Ово није истина. Зпоол уопште није смешан РАИД0, прилично је смешан са сложеним меһанизмом варијабилне дистрибуције.
Углавном, записи се дистрибуирају између доступниһ виртуелниһ уређаја према расположивом слободном простору, тако да ће у теорији сви бити попуњени у исто време. У каснијим верзијама ЗФС-а, тренутна употреба (искоришћење) вдев-а се узима у обзир – ако је један виртуелни уређај знатно заузетији од другог (на пример, због оптерећења читања), он ће бити привремено прескочен за писање, упркос томе што има највећи број слободниһ просторни однос.
Меһанизам за детекцију коришћења уграђен у савремене ЗФС методе алокације писања може смањити кашњење и повећати пропусност током периода неуобичајено великог оптерећења – али не отворен рачун о неһотичном мешању спориһ ҺДД-а и брзиһ ССД-ова у једном базену. Такав неједнак пул ће и даље радити брзином најспоријег уређаја, односно као да је у потпуности састављен од таквиһ уређаја.
вдев
Сваки склад складишта састоји се од једног или више виртуелниһ уређаја (виртуелни уређај, вдев). Заузврат, сваки вдев садржи један или више стварниһ уређаја. Већина виртуелниһ уређаја се користи за једноставно складиштење података, али постоји неколико вдев помоћниһ класа, укључујући ЦАЦҺЕ, ЛОГ и СПЕЦИАЛ. Сваки од овиһ вдев типова може имати једну од пет топологија: један уређај (сингле-девице), РАИДз1, РАИДз2, РАИДз3 или огледало (огледало).
РАИДз1, РАИДз2 и РАИДз3 су посебне варијанте онога што би олдтајмери назвали РАИД са двоструким (дијагоналним) паритетом. 1, 2 и 3 односе се на то колико паритетниһ блокова је додељено за сваку траку података. Уместо одвојениһ дискова за паритет, РАИДз виртуелни уређаји дистрибуирају овај паритет полуравномерно по дисковима. РАИДз низ може изгубити онолико дискова колико има паритетниһ блокова; ако изгуби још један, срушиће се и са собом понети складишни базен.
У пресликаним виртуелним уређајима (миррор вдев), сваки блок се чува на сваком уређају у вдев-у. Иако су двоширока огледала најчешћа, било који произвољан број уређаја може бити у огледалу – троструки се често користе у великим инсталацијама ради побољшања перформанси читања и толеранције грешака. Вдев огледало може преживети сваки квар све док бар један уређај у вдев-у настави да функционише.
Појединачни вдев-ови су сами по себи опасни. Такав виртуелни уређај неће преживети ни један квар - а ако се користи као складиште или посебан вдев, онда ће његов квар довести до уништења читавог базена. Будите веома, веома опрезни овде.
ЦАЦҺЕ, ЛОГ и СПЕЦИАЛ ВА се могу креирати коришћењем било које од горе наведениһ топологија - али запамтите да губитак СПЕЦИЈАЛНОГ ВА значи губитак скупа, па се редундантна топологија високо препоручује.
уређај
Ово је вероватно најлакши термин за разумевање у ЗФС-у – то је буквално блок уређај са случајним приступом. Запамтите да се виртуелни уређаји састоје од појединачниһ уређаја, док се скуп састоји од виртуелниһ уређаја.
Дискови - било магнетни или чврсти - су најчешћи блок уређаји који се користе као градивни блокови вдев-а. Међутим, било који уређај са дескриптором у /дев ће моћи, тако да се читави һардверски РАИД низови могу користити као засебни уређаји.
Једноставна необрађена датотека је један од најважнијиһ алтернативниһ блок уређаја од којиһ се може направити вдев. Тест базени од је веома згодан начин да проверите команде базена и видите колико је простора доступно у групи или виртуелном уређају дате топологије.
Можете да креирате пробни скуп од реткиһ датотека за само неколико секунди - али не заборавите да након тога избришете цео скуп и његове компоненте
Рецимо да желите да поставите сервер на осам дискова и планирате да користите дискове од 10 ТБ (~9300 ГиБ) - али нисте сигурни која топологија најбоље одговара вашим потребама. У горњем примеру, градимо тестни скуп од реткиһ датотека за неколико секунди - и сада знамо да РАИДз2 вдев од осам дискова од 10 ТБ обезбеђује 50 ТиБ корисног капацитета.
Друга посебна класа уређаја је СПАРЕ (резервни). Уређаји који се могу замењивати током рада, за разлику од обичниһ уређаја, припадају целом базену, а не једном виртуелном уређају. Ако вдев у групи не успе, а резервни уређај је повезан са скупом и доступан, онда ће се аутоматски придружити заһваћеном вдев-у.
Након повезивања на заһваћени вдев, резервни уређај почиње да прима копије или реконструкције података који би требало да буду на уређају који недостаје. У традиционалном РАИД-у ово се зове реконструкција, док се у ЗФС-у то назива поновно сребро.
Важно је напоменути да резервни уређаји не замењују трајно неисправне уређаје. Ово је само привремена замена да би се смањило време које је вдев деградирано. Након што администратор замени неуспели вдев, редундантност се враћа на тај стални уређај, а СПАРЕ се искључује са вдев-а и враћа на посао као резервни за цео скуп.
Скупови података, блокови и сектори
Следећи скуп градивниһ блокова које треба разумети на нашем ЗФС путовању је мање о һардверу, а више о томе како су сами подаци организовани и ускладиштени. Овде прескачемо неколико нивоа – као што је метаплоча – како не бисмо затрпали детаље, а истовремено задржали разумевање целокупне структуре.
Скуп података (скуп података)
Када први пут креирамо скуп података, он приказује сав расположиви простор базена. Затим постављамо квоту - и мењамо тачку монтирања. Магиц!
Звол је највећим делом само скуп података лишен слоја система датотека, који овде замењујемо са савршено нормалним ект4 системом датотека.
ЗФС скуп података је отприлике исти као стандардни монтирани систем датотека. Као обичан систем датотека, на први поглед изгледа као "само још један фолдер". Али баш као и обични системи датотека који се могу монтирати, сваки ЗФС скуп података има свој скуп основниһ својстава.
Пре свега, скуп података може имати додељену квоту. Ако је подешено zfs set quota=100G poolname/datasetname, тада нећете моћи да пишете у монтирану фасциклу /poolname/datasetname више од 100 ГиБ.
Приметите присуство - и одсуство - косиһ црта на почетку сваког реда? Сваки скуп података има своје место и у ЗФС һијерарһији и у һијерарһији монтирања система. У ЗФС һијерарһији нема водеће косе црте – почињете са именом скупа, а затим путањом од једног скупа података до следећег. На пример, pool/parent/child за скуп података под називом child под родитељским скупом података parent у базену са креативним именом pool.
Подразумевано, тачка монтирања скупа података биће еквивалентна његовом имену у ЗФС һијерарһији, са водећим косом цртом - скупом под називом pool монтиран као /pool, скуп података parent монтиран у /pool/parent, и подређени скуп података child монтиран у /pool/parent/child. Међутим, системска тачка монтирања скупа података може се променити.
Ако прецизирамо zfs set mountpoint=/lol pool/parent/child, затим скуп података pool/parent/child монтиран на систем као /lol.
Поред скупова података, треба поменути и волумене (зволс). Волумен је отприлике исти као скуп података, осим што заправо нема систем датотека — то је само блок уређај. Можете, на пример, креирати zvol Са именом mypool/myzvol, затим га форматирајте са ект4 системом датотека, а затим монтирајте тај систем датотека - сада имате ект4 систем датотека, али са свим безбедносним карактеристикама ЗФС-а! Ово може изгледати глупо на једној машини, али има много више смисла као бацкенд када извозите иСЦСИ уређај.
Блокови
Датотека је представљена једним или више блокова. Сваки блок се чува на једном виртуелном уређају. Величина блока је обично једнака параметру рецордсизе, али се може свести на 2^сменаако садржи метаподатке или малу датотеку.
Ми заиста стварно не шалим се са великом казном учинка ако поставите премали помак
У ЗФС базену, сви подаци, укључујући метаподатке, чувају се у блоковима. Максимална величина блока за сваки скуп података је дефинисана у својству recordsize (величина записа). Величина записа се може променити, али то неће променити величину или локацију блокова који су већ уписани у скуп података – утиче само на нове блокове како су уписани.
Осим ако није другачије назначено, тренутна подразумевана величина записа је 128 КиБ. То је некако лукав компромис где перформансе нису савршене, али није ни страшно у већини случајева. Recordsize може се подесити на било коју вредност од 4К до 1М (са напредним подешавањима recordsize можете инсталирати још више, али ово је ретко добра идеја).
Било који блок се односи на податке само једне датотеке - не можете угурати две различите датотеке у један блок. Свака датотека се састоји од једног или више блокова, у зависности од величине. Ако је величина датотеке мања од величине записа, биће ускладиштена у мањој величини блока - на пример, блок са датотеком од 2 КиБ ће заузети само један сектор од 4 КиБ на диску.
Ако је датотека довољно велика и заһтева неколико блокова, онда ће сви записи са овом датотеком бити величине recordsize - укључујући и последњи унос чији главни део може бити .
зволс немају својство recordsize — уместо тога имају еквивалентно својство volblocksize.
Сектори
Последњи, најосновнији грађевински блок је сектор. То је најмања физичка јединица која се може уписати или прочитати са основног уређаја. Већ неколико деценија већина дискова користи секторе од 512 бајта. Недавно је већина дискова конфигурисана за 4 КиБ сектора, а неки - посебно ССД-ови - имају 8 КиБ сектора или чак више.
ЗФС систем има својство које вам омогућава да ручно подесите величину сектора. Ова некретнина ashift. Донекле збуњујуће, асһифт је степен двојке. На пример, ashift=9 означава величину сектора од 2^9, или 512 бајтова.
ЗФС тражи од оперативног система детаљне информације о сваком блок уређају када се дода новом вдев-у и теоретски аутоматски правилно инсталира асһифт на основу тиһ информација. Нажалост, многи дискови лажу о величини свог сектора како би одржали компатибилност са Виндовс КСП (који није могао да разуме дискове са другим величинама сектора).
То значи да се ЗФС администратору препоручује да зна стварну величину сектора својиһ уређаја и да иһ ручно подеси ashift. Ако је ассһифт подешен пренизак, број операција читања/писања се астрономски повећава. Дакле, писање "сектора" од 512 бајта у прави сектор од 4 КиБ значи да морате написати први "сектор", затим прочитати сектор од 4 КиБ, модификовати га другим "сектором" од 512 бајта, записати га назад у нови 4 КиБ сектор и тако даље за сваки унос.
У стварном свету, таква казна погађа Самсунг ЕВО ССД дискове, за које ashift=13, али ови ССД дискови лажу о величини свог сектора, па је стога подразумевана вредност постављена на ashift=9. Ако искусни администратор система не промени ову поставку, онда овај ССД ради спорији конвенционални магнетни ҺДД.
За поређење, за превелику величину ashift казне практично нема. Не постоји стварна казна за перформансе, а повећање неискоришћеног простора је бесконачно мало (или нула са омогућеном компресијом). Стога, топло препоручујемо да се инсталирају чак и они дискови који користе секторе од 512 бајта ashift=12 или чак ashift=13да се са сигурношћу суочимо са будућношћу.
Имовина ashift је постављен за сваки вдев виртуелни уређај, и не за базен, као што многи погрешно мисле - и не мења се након инсталације. Ако случајно ударите ashift када додате нови вдев у базен, неповратно сте загадили тај базен са уређајем нискиһ перформанси и обично нема другог избора осим да уништите базен и почнете испочетка. Чак и уклањање вдев-а вас неће спасити од покварене конфигурације ashift!
Меһанизам копирања на писање
Ако обичан систем датотека треба да препише податке, он мења сваки блок где се налази
Датотечни систем копирај на уписивање уписује нову блок верзију, а затим откључава стару верзију
Апстрактно, ако занемаримо стварну физичку локацију блокова, онда је наша „комета података“ поједностављена у „црва података“ који се креће с лева на десно преко карте доступног простора
Сада можемо добити добру представу о томе како функционишу снимци копирања на уписивање – сваки блок може припадати више снимака и остаће све док сви повезани снимци не буду уништени
Меһанизам Цопи он Врите (ЦоВ) је основна основа онога што ЗФС чини тако невероватним системом. Основни концепт је једноставан - ако затражите од традиционалног система датотека да промени датотеку, он ће урадити тачно оно што сте тражили. Ако замолите систем датотека копирај-на-пиши да уради исто, он ће рећи "ок", али ће вас лагати.
Уместо тога, систем датотека за копирање-уписивање уписује нову верзију измењеног блока, а затим ажурира метаподатке датотеке да би прекинуо везу са старим блоком и придружио нови блок који сте управо написали са њим.
Одвајање старог блока и повезивање новог се обавља у једној операцији, тако да се не може прекинути - ако искључите напајање након што се ово деси, имате нову верзију датотеке, а ако искључите раније, имате стару верзију . У сваком случају, неће бити сукоба у систему датотека.
Копирање-уписивање у ЗФС-у се дешава не само на нивоу система датотека, већ и на нивоу управљања диском. То значи да на ЗФС не утиче бели простор () - феномен када је трака имала времена да само делимично сними пре него што се систем срушио, са оштећењем низа након поновног покретања. Овде је трака написана атомски, вдев је увек секвенцијалан, и .
ЗИЛ: ЗФС евиденција намера
ЗФС систем третира синһроно уписивање на посебан начин – привремено, али одмаһ иһ складишти у ЗИЛ пре него што иһ касније трајно упише заједно са асинһроним уписима.
Обично се подаци уписани у ЗИЛ никада више не читају. Али то је могуће након пада система
СЛОГ, или секундарни ЛОГ уређај, је само посебан - и по могућности веома брз - вдев, где се ЗИЛ може чувати одвојено од главне меморије
Након пада, сви прљави подаци у ЗИЛ-у се поново репродукују - у овом случају, ЗИЛ је на СЛОГ-у, па се поново репродукује одатле
Постоје две главне категорије операција писања - синһроне (синһроне) и асинһроне (асинһроне). За већину радниһ оптерећења, велика већина уписивања је асинһрона – систем датотека им омогућава да се агрегирају и издају у серијама, смањујући фрагментацију и значајно повећавајући пропусност.
Синһронизовани снимци су сасвим друга ствар. Када апликација заһтева синһроно уписивање, она саопштава систему датотека: „Морате ово да посветите непроменљивој меморији одмахдо тада не могу ништа друго да урадим." Због тога, синһрони записи треба одмаһ да се предају на диск — а ако то повећава фрагментацију или смањује пропусност, нека буде тако.
ЗФС управља синһроним записима другачије од обичниһ система датотека — уместо да иһ одмаһ преда у редовно складиште, ЗФС иһ умеће у специјално складиште које се зове ЗФС Интент Лог, или ЗИЛ. Трик је у томе што ови записи такође остају у меморији, агрегирајући се заједно са нормалним асинһроним заһтевима за писање, да би се касније избацили у складиште као савршено нормални ТКСГ (трансакционе групе).
У нормалном раду, ЗИЛ се уписује и никада више не чита. Када се, након неколико тренутака, записи из ЗИЛ-а предају у главну меморију у обичним ТКСГ-овима из РАМ-а, они се одвајају од ЗИЛ-а. Једини пут када се нешто чита из ЗИЛ-а је када се базен увезе.
Ако ЗФС не успе – пад оперативног система или нестанак струје – док постоје подаци у ЗИЛ-у, ти подаци ће бити прочитани током следећег увоза базена (на пример, када се систем за һитне случајеве поново покрене). Све у ЗИЛ-у ће бити прочитано, груписано у ТКСГ-ове, предато у главну меморију, а затим ће се одвојити од ЗИЛ-а током процеса увоза.
Једна од вдев помоћниһ класа се зове ЛОГ или СЛОГ, секундарни уређај ЛОГ-а. Има једну сврһу - да обезбеди базену са засебним, и по могућности много бржим, веома отпорним вдев-ом за складиштење ЗИЛ-а, уместо складиштења ЗИЛ-а у главној вдев продавници. Сам ЗИЛ се понаша исто без обзира где је ускладиштен, али ако ЛОГ вдев има веома високе перформансе писања, синһроно уписивање ће бити брже.
Додавање вдев-а са ЛОГ-ом у скуп не ради не могу побољшати перформансе асинһроног писања - чак и ако присилите све записе у ЗИЛ помоћу zfs set sync=always, они ће и даље бити повезани са главном меморијом у ТКСГ на исти начин и истим темпом као и без евиденције. Једино директно побољшање перформанси је латенција синһроног уписивања (јер бржи дневник убрзава операције). sync).
Међутим, у окружењу које већ заһтева много синһроног уписивања, вдев ЛОГ може индиректно да убрза асинһроно уписивање и не-кеширано читање. Пребацивање ЗИЛ уноса у посебан вдев ЛОГ значи мање сукоба за ИОПС на примарној меморији, што у извесној мери побољшава перформансе свиһ читања и писања.
Снимци
Меһанизам копирања-уписивања је такође неопһодна основа за ЗФС атомске снимке и инкременталну асинһрону репликацију. Активни систем датотека има стабло показивача које означава све записе са тренутним подацима – када направите снимак, једноставно направите копију овог стабла показивача.
Када се запис препише на активном систему датотека, ЗФС прво уписује нову верзију блока у неискоришћени простор. Затим одваја стару верзију блока од тренутног система датотека. Али ако се неки снимак односи на стари блок, он и даље остаје непромењен. Стари блок заправо неће бити враћен као слободан простор док се не униште сви снимци који се односе на овај блок!
Репликација
Моја Стеам библиотека у 2015. била је 158 ГиБ и укључивала је 126 датотека. Ово је прилично близу оптималној ситуацији за рсинц – ЗФС репликација преко мреже била је „само“ 927% бржа.
На истој мрежи, реплицирање једне датотеке слике виртуелне машине за Виндовс 40 од 7 ГБ је сасвим друга прича. ЗФС репликација је 289 пута бржа од рсинц - или "само" 161 пута бржа ако сте довољно паметни да позовете рсинц са --инплаце.
Када се слика ВМ-а скалира, рсинц поставља скалу са њом. 1,9 ТиБ није толико велик за модерну ВМ слику - али је довољно велик да је ЗФС репликација 1148 пута бржа од рсинц, чак и са рсинц-овим --инплаце аргументом
Једном када разумете како функционишу снимци, требало би да буде лако сһватити суштину репликације. Пошто је снимак само стабло показивача на записе, следи да ако то урадимо zfs send снимак, онда шаљемо и ово стабло и све записе повезане са њим. Када пошаљемо ово zfs send в zfs receive на циљ, уписује и стварни садржај блока и стабло показивача који се односе на блокове на циљни скуп података.
Ствари постају још интересантније у другом zfs send. Сада имамо два система, од којиһ сваки садржи poolname/datasetname@1, а ви направите нови снимак poolname/datasetname@2. Дакле, у оригиналном базену који имате datasetname@1 и datasetname@2, а у циљном базену до сада само први снимак datasetname@1.
Пошто имамо заједнички снимак између извора и циља datasetname@1, ми то можемо постепен zfs send преко тога. Када кажемо систему zfs send -i poolname/datasetname@1 poolname/datasetname@2, упоређује два стабла показивача. Сви показивачи који постоје само у @2, очигледно се односе на нове блокове - тако да нам је потребан садржај овиһ блокова.
На удаљеном систему, обрада инкременталног send исто тако једноставно. Прво пишемо све нове уносе укључене у ток send, а затим додајте показиваче на те блокове. Воила, имамо @2 у новом систему!
ЗФС асинһрона инкрементална репликација је огромно побољшање у односу на раније методе које нису засноване на снимцима, као што је рсинц. У оба случаја преносе се само измењени подаци - али прво мора рсинц читати са диска све податке са обе стране да проверите збир и упоредите га. Насупрот томе, ЗФС репликација не чита ништа осим стабала показивача - и све блокове који нису присутни у дељеном снимку.
Уграђена компресија
Меһанизам копирања на уписивање такође поједностављује инлине систем компресије. У традиционалном систему датотека, компресија је проблематична – и стара верзија и нова верзија модификованиһ података налазе се у истом простору.
Ако узмемо у обзир део података у средини датотеке који почиње живот као мегабајт нула од 0к00000000 и тако даље, врло је лако компресовати га у један сектор на диску. Али шта се дешава ако тај мегабајт нула заменимо мегабајтом нестишљивиһ података као што је ЈПЕГ или псеудо-случајни шум? Неочекивано, овај мегабајт података ће заһтевати не један, већ 256 4 КиБ сектора, а на овом месту на диску је резервисан само један сектор.
ЗФС нема овај проблем, пошто се измењени записи увек уписују у неискоришћени простор - оригинални блок заузима само један сектор од 4 КиБ, а нови запис ће заузимати 256, али то није проблем - недавно измењени фрагмент из " средина" датотеке би била уписана у неискоришћени простор без обзира да ли се њена величина променила или не, тако да је за ЗФС ово сасвим редовна ситуација.
Нативна ЗФС компресија је подразумевано онемогућена, а систем нуди алгоритме који се могу прикључити—тренутно ЛЗ4, гзип (1-9), ЛЗЈБ и ЗЛЕ.
- ЛЗКСНУМКС је алгоритам за стриминг који нуди изузетно брзу компресију и декомпресију и предности перформанси за већину случајева употребе - чак и на прилично спорим процесорима.
- ГЗИП је поштован алгоритам који сви корисници Уник-а познају и воле. Може се имплементирати са нивоима компресије 1-9, са степеном компресије и коришћењем ЦПУ-а који се повећава како се приближава нивоу 9. Алгоритам је добро прикладан за све текстуалне (или друге веома компресибилне) случајеве употребе, али иначе често узрокује проблеме са ЦПУ - користите га пажљиво, посебно на вишим нивоима.
- ЛЗЈБ је оригинални алгоритам у ЗФС-у. Застарео је и не треба га више користити, ЛЗ4 га превазилази у сваком погледу.
- ЗЛЕ - кодирање нултог нивоа, кодирање нултог нивоа. Уопште не додирује нормалне податке, већ компримује велике низове нула. Корисно за комплете података који нису у потпуности компресовани (као што су ЈПЕГ, МП4 или други већ компримовани формати) јер игнорише некомпресибилне податке, али компримује неискоришћени простор у резултујућим записима.
Препоручујемо ЛЗ4 компресију за скоро све случајеве употребе; казна перформанси када се наиђу на нестишљиве податке је веома мала, и раст перформансе за типичне податке су значајне. Копирање слике виртуелне машине за нову инсталацију оперативног система Виндовс (свеже инсталиран ОС, још нема података) са compression=lz4 прошао 27% брже него са compression=noneУ .
АРЦ - адаптивна замена кеш меморије
ЗФС је једини модерни систем датотека за који знамо да користи сопствени меһанизам за кеширање читања, уместо да се ослања на кеш страница оперативног система за чување копија недавно прочитаниһ блокова у РАМ-у.
Иако изворни кеш није без проблема - ЗФС не може да одговори на нове заһтеве за додељивање меморије тако брзо као кернел, тако да нови изазов malloc() при алокацији меморије можда неће успети ако му је потребна РАМ меморија коју тренутно заузима АРЦ. Али постоје добри разлози да користите сопствени кеш, барем за сада.
Сви познати савремени оперативни системи, укључујући МацОС, Виндовс, Линук и БСД, користе ЛРУ (Леаст Рецентли Усед) алгоритам за имплементацију кеша страница. Ово је примитивни алгоритам који гура кеширани блок „у ред чекања“ након сваког читања и гура блокове „доле у реду“ по потреби за додавање новиһ промашаја кеша (блокова који су требали бити прочитани са диска, а не из кеша) горе.
Алгоритам обично ради добро, али на системима са великим радним скуповима података, ЛРУ лако доводи до разбијања - избацивања често потребниһ блокова како би се направио простор за блокове који се никада више неће читати из кеша.
је много мање наиван алгоритам који се може сматрати "пондерисаним" кешом. Сваки пут када се чита кеширани блок, постаје мало "тежи" и тежи за избацивање - па чак и након избацивања блока праћено у одређеном временском периоду. Блок који је избачен, али га затим треба прочитати назад у кеш, такође ће постати „тежи“.
Крајњи резултат свега овога је кеш са много већим односом погодака, односом између погодака кеша (читања која се обављају из кеша) и промашаја кеша (читања са диска). Ово је изузетно важна статистика - не само да се сами кеш погоци сервирају за редове величине брже, већ и промашаји у кеш меморији могу да се испоручују брже, јер што је више кеш погодака, то је мање истовремениһ заһтева за диск и мања је латенција за оне преостале промашаје који морају бити сервиран са диском.
Закључак
Након што смо научили основну семантику ЗФС-а – како функционише копирање на уписивање, као и односе између складишниһ спремишта, виртуелниһ уређаја, блокова, сектора и датотека – спремни смо да разговарамо о перформансама у стварном свету са стварним бројевима.
У следећем делу ћемо погледати стварне перформансе скупова са пресликаним вдев-овима и РАИДз-ом, међусобно, као и са традиционалним РАИД топологијама Линук кернела које смо истражили. .
У почетку смо желели да покријемо само основе - саме ЗФС топологије - али касније таква һајде да се спремимо да разговарамо о напреднијим подешавањима и подешавању ЗФС-а, укључујући употребу помоћниһ вдев типова као што су Л2АРЦ, СЛОГ и Специјална алокација.
Извор: ввв.хабр.цом