Тази пролет вече обсъдихме някои уводни теми, напр. как да проверите скоростта на вашите устройства и какво е RAID. Във втората от тях дори обещахме да продължим да изучаваме производителността на различни многодискови топологии в ZFS. Това е следващото поколение файлова система, която сега се внедрява навсякъде ябълка до Ubuntu.

Е, днес е най-добрият ден да се запознаете със ZFS, любопитни читатели. Просто знайте, че според скромната оценка на разработчика на OpenZFS Мат Аренс, „наистина е трудно“.

Но преди да стигнем до числата – а такива ще има, обещавам – за всички варианти на конфигурацията на ZFS с осем диска, трябва да поговорим за като Като цяло ZFS съхранява данни на диск.

Zpool, vdev и устройство

Тази пълна диаграма на пула включва три спомагателни vdev, по един от всеки клас и четири за RAIDz2

Обикновено няма причина да създавате набор от несъвпадащи типове и размери на vdev - но ако искате, нищо не ви пречи да го направите

За да разберете наистина файловата система ZFS, трябва да разгледате отблизо действителната й структура. Първо, ZFS обединява традиционните слоеве за управление на обем и файлова система. Второ, той използва транзакционен механизъм за копиране при запис. Тези характеристики означават, че системата е структурно много различна от конвенционалните файлови системи и RAID масиви. Първият набор от основни градивни елементи, които трябва да разберете, са пулът за съхранение (zpool), виртуалното устройство (vdev) и реалното устройство (устройство).

zpool

Пулът за съхранение на zpool е най-горната ZFS структура. Всеки пул съдържа едно или повече виртуални устройства. На свой ред всеки от тях съдържа едно или повече реални устройства (устройства). Виртуалните басейни са самостоятелни единици. Един физически компютър може да съдържа два или повече отделни пула, но всеки от тях е напълно независим от другите. Пуловете не могат да споделят виртуални устройства.

Резервирането на ZFS е на ниво виртуално устройство, а не на ниво пул. Няма абсолютно никакво излишък на ниво пул—ако се загуби vdev или специален vdev, целият пул се губи заедно с него.

Съвременните пулове за съхранение могат да преживеят загубата на кеша или журнала на виртуално устройство - въпреки че могат да загубят малко количество мръсни данни, ако загубят vdev журнала по време на прекъсване на захранването или срив на системата.

Съществува често срещано погрешно схващане, че ZFS „лентите с данни“ се записват в целия пул. Това не е вярно. Zpool не е смешен RAID0, той е по-скоро смешен JBOD със сложен механизъм за променливо разпределение.

В по-голямата си част записите се разпределят между наличните виртуални устройства според наличното свободно пространство, така че на теория всички ще бъдат запълнени едновременно. По-новите версии на ZFS вземат предвид текущото използване на vdev (изхвърляне) - ако едно виртуално устройство е значително по-натоварено от друго (например поради натоварване при четене), то ще бъде временно пропуснато за запис, въпреки че има най-високото съотношение на свободно пространство .

Механизмът за откриване на рециклиране, вграден в съвременните методи за разпределяне на запис на ZFS, може да намали латентността и да увеличи пропускателната способност по време на периоди на необичайно високо натоварване - но не го прави картбланш до неволно смесване на бавни HDD и бързи SSD в един пул. Такъв неравномерен пул все още ще работи със скоростта на най-бавното устройство, т.е. сякаш е изцяло съставен от такива устройства.

vdev

Всеки пул за съхранение се състои от едно или повече виртуални устройства (vdev). На свой ред всеки vdev включва едно или повече реални устройства. Повечето виртуални устройства се използват за просто съхранение на данни, но има няколко vdev помощни класа, включително CACHE, LOG и SPECIAL. Всеки от тези типове vdev може да има една от петте топологии: едно устройство, RAIDz1, RAIDz2, RAIDz3 или огледало.

RAIDz1, RAIDz2 и RAIDz3 са специални разновидности на това, което старите хора биха нарекли RAID с двоен (диагонален) паритет. 1, 2 и 3 се отнасят до това колко блока за паритет са разпределени за всяка лента за данни. Вместо да имат отделни дискове за осигуряване на паритет, виртуалните RAIDz устройства разпределят паритета полуравномерно между дисковете. Един RAIDz масив може да загуби толкова дискове, колкото има блокове за паритет; ако загуби друг, той ще се провали и ще вземе пула за съхранение със себе си.

В огледалните виртуални устройства (mirror vdev), всеки блок се съхранява на всяко устройство във vdev. Въпреки че огледалата с две ширини са най-често срещаните, едно огледало може да съдържа произволен брой устройства - в големи инсталации тройните често се използват за подобряване на производителността на четене и устойчивостта на грешки. Огледалото на vdev може да преживее всяка повреда, стига поне едно устройство във vdev да остане работещо.

Единичните vdev са опасни по своята същност. Такова виртуално устройство няма да преживее нито една повреда - и ако се използва като хранилище или специален vdev, тогава повредата му ще доведе до унищожаването на целия пул. Бъдете много, много внимателни тук.

CACHE, LOG и SPECIAL виртуални устройства могат да бъдат създадени във всяка от горните топологии - но не забравяйте, че загубата на SPECIAL виртуално устройство означава загуба на пула, така че излишната топология е силно препоръчителна.

приспособление

Това е може би най-лесният за разбиране термин в ZFS - това е буквално блоково устройство с произволен достъп. Не забравяйте, че виртуалните устройства са съставени от отделни устройства, а пулът е съставен от виртуални устройства.

Дисковете, магнитни или твърдотелни, са най-често срещаните блокови устройства, използвани като градивни елементи на vdev. Въпреки това всяко устройство с дескриптор в /dev ще свърши работа - така че цели хардуерни RAID масиви могат да се използват като отделни устройства.

Простият необработен файл е едно от най-важните алтернативни блокови устройства, от които може да се изгради vdev. Тестови басейни от редки файлове е много удобен начин да проверите командите на пула и да видите колко място е налично в пула или виртуалното устройство с дадена топология.

Можете да създадете тестов пул от редки файлове само за няколко секунди - но не забравяйте след това да изтриете целия пул и неговите компоненти

Да приемем, че искате сървър с осем диска и планирате да използвате 10 TB (~9300 GiB) дискове – но не сте сигурни коя топология отговаря най-добре на вашите нужди. В примера по-горе ние изграждаме тестов пул от разредени файлове за няколко секунди - и сега знаем, че RAIDz2 vdev от осем 10 TB диска осигурява 50 TiB използваем капацитет.

Друг специален клас устройства са SPARE. Устройствата с гореща смяна, за разлика от обикновените устройства, принадлежат към целия пул, а не към едно виртуално устройство. Ако някое vdev в пула се повреди и резервно устройство е свързано към пула и е налично, то автоматично ще се присъедини към засегнатия vdev.

Веднъж свързано със засегнатия vdev, заместващото устройство започва да получава копия или реконструкции на данните, които трябва да са на липсващото устройство. В традиционния RAID това се нарича "rebuilding", а в ZFS е "resilvering".

Важно е да се отбележи, че заместващите устройства не заменят окончателно повредените устройства. Това е само временна замяна, за да се намали времето, необходимо на vdev за деградиране. След като администраторът замени неуспешното vdev устройство, резервирането се възстановява на това постоянно устройство и SPARE се изключва от vdev и се връща като резервно за целия пул.

Набори от данни, блокове и сектори

Следващият набор от градивни елементи, които трябва да разберете в нашето ZFS пътуване, се отнасят по-малко до хардуера и повече до начина, по който се организират и съхраняват самите данни. Пропускаме няколко слоя тук - като metaslab - за да избегнем претрупването на детайлите, като същевременно поддържаме разбиране за цялостната структура.

Набор от данни

Когато за първи път създадем набор от данни, той показва цялото налично пространство в пула. След това задаваме квотата - и променяме точката на монтиране. Магия!

Zvol е най-вече просто набор от данни, лишен от своя слой на файловата система, който заместваме тук с напълно нормална файлова система ext4

Наборът от данни на ZFS е приблизително същият като стандартна монтирана файлова система. Подобно на обикновена файлова система, на пръв поглед изглежда, че е „просто още една папка“. Но също като обикновените монтирани файлови системи, всеки ZFS набор от данни има свой собствен набор от основни свойства.

На първо място, даден набор от данни може да има назначена квота. Ако инсталирате zfs set quota=100G poolname/datasetname, тогава няма да можете да пишете в монтираната папка /poolname/datasetname повече от 100 GiB.

Забелязвате наличието и липсата на наклонени черти в началото на всеки ред? Всеки набор от данни има свое място както в йерархията на ZFS, така и в йерархията на монтиране на системата. В йерархията на ZFS няма водеща наклонена черта - започвате с името на пула и след това пътя от един набор от данни към следващия. Например, pool/parent/child за набор от данни с име child под родителския набор от данни parent в пул с творческо име pool.

По подразбиране точката на монтиране на набор от данни ще бъде еквивалентна на името му в йерархията на ZFS, с водеща наклонена черта - пула с име pool монтиран като /pool, набор от данни parent монтиран в /pool/parentи дъщерния набор от данни child монтиран в /pool/parent/child. Въпреки това системната точка на монтиране на набора от данни може да бъде променена.

Ако посочим zfs set mountpoint=/lol pool/parent/child, след това наборът от данни pool/parent/child монтиран в системата като /lol.

В допълнение към наборите от данни трябва да споменем обеми (zvol). Томът е приблизително същото като набор от данни, с изключение на това, че всъщност няма файлова система - това е просто блоково устройство. Можете например да създадете zvol С име mypool/myzvol, след това го форматирайте с ext4 файлова система и след това монтирайте тази файлова система - сега имате ext4 файлова система, но с всички функции за сигурност на ZFS! Това може да изглежда глупаво на един компютър, но има много повече смисъл като бекенд при експортиране на iSCSI устройство.

блокове

Файлът е представен от един или повече блокове. Всеки блок се съхранява на едно виртуално устройство. Размерът на блока обикновено е равен на параметъра рекорден размер, но може да се намали до 2^ashift, ако съдържа метаданни или малък файл.

Ние наистина наистина Не се шегуваме с огромната загуба на производителност, ако зададете ashift твърде ниско

В ZFS пул всички данни, включително метаданните, се съхраняват в блокове. Максималният размер на блока за всеки набор от данни е определен в свойството recordsize (рекорден размер). Размерът на записа може да се промени, но това няма да промени размера или местоположението на всички блокове, които вече са записани в набора от данни - това засяга само новите блокове, докато се записват.

Освен ако не е указано друго, текущият размер на записа по подразбиране е 128 KiB. Това е доста труден компромис, при който производителността няма да е перфектна, но в повечето случаи няма да е ужасна. Recordsize може да се настрои на произволна стойност от 4K до 1M (с допълнителни настройки recordsize можете да инсталирате дори повече, но това рядко е добра идея).

Всеки блок се отнася до данните само на един файл - не можете да стиснете два различни файла в един блок. Всеки файл се състои от един или повече блокове, в зависимост от неговия размер. Ако размерът на файла е по-малък от размера на записа, той ще бъде съхранен в по-малък блок - например блок с файл от 2 KiB ще заема само един сектор от 4 KiB на диска.

Ако файлът е достатъчно голям, за да изисква няколко блока, тогава всички записи в този файл ще бъдат с размер recordsize - включително последния запис, чиято основна част може да бъде неизползвано пространство.

томовете zvol нямат свойството recordsize - вместо това те имат еквивалентното свойство volblocksize.

Сектори

Последният, най-основен градивен елемент е секторът. Това е най-малката физическа единица, която може да бъде записана или прочетена от хост устройство. В продължение на няколко десетилетия повечето дискове използваха 512-байтови сектори. В наши дни повечето устройства са конфигурирани за 4 KiB сектори, а някои - особено SSD - са конфигурирани за 8 KiB сектора или дори по-големи.

ZFS има функция, която ви позволява ръчно да зададете размера на сектора. Този имот ashift. Донякъде объркващо, ashift е степен на две. Например, ashift=9 означава размер на сектора 2^9 или 512 байта.

ZFS иска от операционната система подробна информация за всяко блоково устройство, когато се добавя към нов vdev, и теоретично автоматично настройва ashift по подходящ начин въз основа на тази информация. За съжаление много дискове лъжат относно размера на техния сектор, за да поддържат съвместимост с Windows XP (който не успя да разбере дискове с други размери на сектора).

Това означава, че е силно препоръчително администраторът на ZFS да знае действителния размер на сектора на своите устройства и да го зададе ръчно ashift. Ако ashift е зададено твърде малко, броят на операциите за четене/запис се увеличава астрономически. И така, записването на 512-байтови "сектори" в реален 4 KiB сектор означава да напишете първия "сектор", след това да прочетете 4 KiB сектора, да го модифицирате с втори 512-байтов "сектор", да го запишете обратно в новия 4 KiB сектор и така нататък за всеки запис.

В реалния свят подобна санкция засяга Samsung EVO SSD, за които трябва да важи ashift=13, но тези SSD лъжат относно размера на техния сектор и следователно по подразбиране е зададено на ashift=9. Освен ако опитен системен администратор не промени тази настройка, този SSD работи по-бавно обикновен магнитен твърд диск.

За сравнение, защото е твърде голям ashift на практика няма наказание. Няма реален удар в производителността и увеличението на неизползваното пространство е безкрайно малко (или нула, ако компресията е активирана). Затова силно препоръчваме да се инсталират дори тези устройства, които използват 512-байтови сектори ashift=12 или ashift=13да гледат уверено в бъдещето.

имот ashift се инсталира за всяко виртуално устройство vdev и не е за басейн, както много хора погрешно смятат - и не се променя след инсталирането. Ако случайно ударите ashift Когато добавите нов vdev към пул, вие безвъзвратно сте замърсили този пул с устройство с ниска производителност и по правило няма друга опция освен да унищожите пула и да започнете отначало. Дори изтриването на vdev няма да ви спаси от повредена настройка ashift!

Механизъм за копиране при запис

Ако обикновена файлова система трябва да пренапише данни, тя променя всеки блок, където се намира

Файловата система за копиране при запис записва нова версия на блока и след това отключва старата версия

В резюме, ако пренебрегнем действителното физическо подреждане на блоковете, нашата „комета за данни“ се опростява до „червей за данни“, който се движи отляво надясно по картата на наличното пространство

Сега можем да добием добра представа как работят моментните снимки за копиране при запис - всеки блок може да принадлежи на множество моментни снимки и ще продължи, докато всички свързани моментни снимки не бъдат унищожени

Механизмът Copy on Write (CoW) е фундаменталната основа на това, което прави ZFS толкова невероятна система. Основната концепция е проста - ако помолите традиционна файлова система да промени файл, тя ще направи точно това, което сте поискали. Ако помолите файлова система за копиране при запис да направи същото, тя ще каже „добре“ – но ще ви излъже.

Вместо това, файловата система за копиране при запис записва нова версия на модифицирания блок и след това актуализира метаданните на файла, за да прекрати връзката на стария блок и да го асоциира с новия блок, който току-що сте написали.

Премахването на връзката на стария блок и свързването на новия се извършва с една операция, така че не може да бъде прекъснато - ако нулирате захранването, след като това се случи, имате нова версия на файла, а ако нулирате захранването преди това, тогава имате старата версия. Във всеки случай няма да има конфликти във файловата система.

Копирането при запис в ZFS се извършва не само на ниво файлова система, но и на ниво управление на диска. Това означава, че ZFS не е податлив на интервали в записа (дупка в RAID) - феномен, при който лентата е била записана само частично преди системата да се срине, с повреда на масива след рестартиране. Тук лентата е написана атомарно, vdev винаги е последователен и Боб е твой чичо.

ZIL: ZFS регистър на намеренията

ZFS обработва синхронните записи по специален начин - съхранява ги временно, но незабавно в ZIL, преди по-късно да ги напише постоянно заедно с асинхронните записи.

Обикновено данните, записани на ZIL, никога не се четат отново. Но това е възможно след повреда на системата

SLOG или вторично LOG устройство е просто специален - и за предпочитане много бърз - vdev, където ZIL може да се съхранява отделно от основното хранилище

След срив всички мръсни данни в ZIL се възпроизвеждат - в този случай ZIL е на SLOG, така че там се възпроизвежда

Има две основни категории записи: синхронни (sync) и асинхронни (async). За повечето работни натоварвания по-голямата част от записите са асинхронни - файловата система им позволява да бъдат агрегирани и издавани на партиди, намалявайки фрагментацията и значително увеличавайки пропускателната способност.

Синхронните записи са съвсем друг въпрос. Когато дадено приложение поиска синхронен запис, то казва на файловата система: „Трябва да зададете това в енергонезависима памет точно сега, а дотогава не мога да направя нищо повече. Следователно синхронните записи трябва незабавно да бъдат ангажирани към диска - и ако това увеличава фрагментацията или намалява пропускателната способност, така да бъде.

ZFS обработва синхронните записи по различен начин от обикновените файлови системи - вместо незабавно да ги изхвърля в редовно хранилище, ZFS ги ангажира в специална област за съхранение, наречена ZFS Intent Log или ZIL. Номерът е, че тези записи също остават в паметта, като се агрегират заедно с нормалните асинхронни заявки за запис, за да бъдат по-късно изхвърлени в хранилището като напълно нормални TXG (групи за транзакции).

При нормална работа ZIL се записва и никога повече не се чете. Когато след няколко минути записите от ZIL са ангажирани в основното хранилище в обикновени TXG от RAM, те се отделят от ZIL. Единственият път, когато нещо се чете от ZIL, е при импортиране на пул.

Ако възникне повреда на ZFS — срив на операционната система или прекъсване на захранването — докато има данни в ZIL, тези данни ще бъдат прочетени по време на следващото импортиране на пула (например, когато системата за преодоляване на срив се рестартира). Всичко, което е в ZIL, ще бъде прочетено, групирано в TXG, ангажирано към основното хранилище и след това отделено от ZIL по време на процеса на импортиране.

Един от помощните класове на vdev се нарича LOG или SLOG, вторично LOG устройство. Той има една задача - да осигури пул с отделно и, за предпочитане, много по-бързо, с много висока устойчивост на запис, vdev устройство за съхранение на ZIL, вместо да съхранява ZIL на основното vdev хранилище. Самият ZIL се държи по същия начин, независимо от мястото за съхранение, но ако vdev с LOG има много висока производителност на запис, тогава синхронните записи ще бъдат по-бързи.

Добавянето на vdev с LOG към пула не работи не мога подобрете производителността на асинхронен запис - дори ако принудите всички записи в ZIL с zfs set sync=always, те все още ще бъдат свързани с основното хранилище в TXG по същия начин и със същото темпо, както без регистрационния файл. Единственото пряко подобрение на производителността е забавянето на синхронното записване (тъй като по-високите скорости на регистрационни файлове правят операциите по-бързи sync).

Въпреки това, в среда, която вече изисква много синхронни записи, vdev LOG може индиректно да ускори асинхронните записи и некешираните четения. Разтоварването на ZIL записи в отделен vdev LOG означава по-малко конкуренция за IOPS на основното хранилище, което подобрява производителността на всички четения и записи до известна степен.

Моментни снимки

Механизмът за копиране при запис също е необходима основа за ZFS атомарни снимки и инкрементална асинхронна репликация. Активната файлова система има указателно дърво, което маркира всички записи с текущи данни - когато правите моментна снимка, вие просто правите копие на това указателно дърво.

Когато запис се презапише върху активната файлова система, ZFS първо записва новата версия на блока в неизползвано пространство. След това отделя старата версия на блока от текущата файлова система. Но ако някоя моментна снимка препраща към стар блок, тя все още остава непроменена. Старият блок всъщност няма да бъде възстановен като свободно пространство, докато всички моментни снимки, препращащи към този блок, не бъдат унищожени!

репликация

Моята Steam библиотека през 2015 г. беше 158 GiB и включваше 126 927 файла. Това е доста близо до оптималната ситуация за rsync - ZFS репликацията през мрежата беше "само" 750% по-бърза.

В същата мрежа репликирането на един файл с изображение на виртуална машина с размер 40 GB на Windows 7 е напълно различна история. Репликацията на ZFS е 289 пъти по-бърза от rsync—или "само" 161 пъти по-бърза, ако сте достатъчно разбираеми, за да извикате rsync с превключвателя --inplace.

Когато VM изображение се мащабира, rsync издава мащаб с него. Размерът от 1,9 TiB не е толкова голям за съвременен VM образ, но е достатъчно голям, че репликацията на ZFS да е 1148 пъти по-бърза от rsync, дори с аргумента rsync --inplace

След като разберете как работят моментните снимки, ще бъде лесно да разберете същността на репликацията. Тъй като моментната снимка е просто дърво от указатели на записи, следва, че ако го направим 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 в новата система!

Асинхронната инкрементална репликация на ZFS е огромно подобрение спрямо по-ранните методи, които не са базирани на моментни снимки, като rsync. И в двата случая се прехвърлят само променените данни - но rsync трябва първо чета от диска всички данни от двете страни, за да проверите сумата и да я сравните. За разлика от това, ZFS репликацията не чете нищо друго освен дървета на указатели - и всички блокове, които не са представени в цялостната моментна снимка.

Вградена компресия

Механизмът за копиране при запис също опростява вградената система за компресиране. В традиционната файлова система компресирането е проблематично - както старата версия, така и новата версия на променените данни са в едно и също пространство.

Ако разгледате част от данните в средата на файл, който започва живота си като мегабайт нули от 0x00000000 и така нататък - много е лесно да го компресирате в един сектор на диска. Но какво се случва, ако заменим този мегабайт нули с мегабайт некомпресируеми данни, като JPEG или псевдослучаен шум? Изведнъж този мегабайт данни ще изисква не един, а 256 сектора от 4 KiB и само един сектор е запазен в това дисково пространство.

ZFS няма този проблем, тъй като модифицираните записи винаги се записват в неизползвано пространство - оригиналният блок заема само един сектор от 4 KiB, а новото записване ще заеме 256, но това не е проблем - наскоро модифициран фрагмент от "средата" на файла ще бъде записана в неизползвано пространство, независимо дали размерът му се е променил или не, така че това е напълно нормална ситуация за ZFS.

Вградената ZFS компресия е деактивирана по подразбиране и системата предлага плъгируеми алгоритми - в момента включително LZ4, gzip (1-9), LZJB и ZLE.

• LZ4 е алгоритъм за поточно предаване, който предлага изключително бърза компресия и декомпресия и предимства в производителността за повечето случаи на употреба - дори при доста бавни процесори.
• GZIP е уважаван алгоритъм, който всички потребители на Unix познават и обичат. Може да се приложи с нива на компресия 1-9, с увеличаване на коефициента на компресия и използване на процесора, докато наближавате ниво 9. Алгоритъмът е много подходящ за всички текстови (или други силно компресируеми) случаи на използване, но често причинява проблеми с процесора в противен случай - използвайте го с повишено внимание, особено при по-високи нива.
• LZJB - оригинален алгоритъм в ZFS. Той е остарял и не трябва повече да се използва, LZ4 е по-добър във всяко отношение.
• ЗЛЕ — кодиране на нулево ниво, кодиране на нулево ниво. Той изобщо не засяга нормалните данни, но компресира големи поредици от нули. Полезно за напълно некомпресирани набори от данни (като JPEG, MP4 или други вече компресирани формати), тъй като игнорира некомпресираните данни, но компресира неизползваното пространство в получените записи.

Препоръчваме LZ4 компресия за почти всички случаи на употреба; намаляването на производителността при работа с некомпресируеми данни е много малко и растеж производителността за типичните данни е значителна. Копиране на изображение на виртуална машина за нова инсталация на операционната система Windows (прясно инсталирана операционна система, все още няма данни вътре) с compression=lz4 премина 27% по-бързо от с compression=none, Аз Н този тест от 2015 г.

ARC - адаптивен заместващ кеш

ZFS е единствената съвременна файлова система, за която знаем, че използва собствен механизъм за кеширане на четене, вместо да разчита на кеша на страницата на операционната система, за да съхранява копия на наскоро прочетени блокове в RAM.

Въпреки че собственият кеш не е без проблеми - ZFS не може да отговори на нови заявки за разпределяне на памет толкова бързо, колкото ядрото, така че ново извикване malloc() заделянето на памет може да се провали, ако изисква RAM, заета в момента от ARC. Но има добри причини да използвате собствения си кеш, поне засега.

Всички познати съвременни операционни системи, включително MacOS, Windows, Linux и BSD, използват алгоритъма LRU (най-малко използвани) за прилагане на кеша на страниците. Това е примитивен алгоритъм, който избутва кеширан блок "в горната част на опашката" след всяко четене и избутва блокове "в дъното на опашката", ако е необходимо, за да добави нови пропуски в кеша (блокове, които е трябвало да бъдат прочетени от диска, а не от кеша) до върха.

Обикновено алгоритъмът работи добре, но на системи с големи работни набори от данни, LRU лесно води до разбиване - изгонване на често необходими блокове, за да освободи място за блокове, които никога няма да бъдат прочетени от кеша отново.

ARC е много по-малко наивен алгоритъм, който може да се счита за „претеглен“ кеш. Всеки път, когато се чете кеширан блок, той става малко по-тежък и по-труден за изгонване - и дори след като блокът бъде изгонен проследени през определен период от време. Блок, който е бил изгонен, но след това трябва да бъде прочетен обратно в кеша, също ще стане по-тежък.

Крайният резултат от всичко това е кеш с много по-високо съотношение на попадения – съотношението между попадения в кеша (четения от кеша) и пропуски (четения от диск). Това е изключително важна статистика - не само че самите кеш удари се обслужват с порядъци по-бързо, пропуските в кеша също могат да се обслужват по-бързо, тъй като колкото повече има кеш удари, толкова по-малко са паралелните заявки към диска и толкова по-ниска е латентността за тези оставащи пропуски които трябва да се обслужват с диск.

Заключение

Сега, след като покрихме основната семантика на ZFS – как работи копирането при запис, както и връзките между пулове за съхранение, виртуални устройства, блокове, сектори и файлове – ние сме готови да обсъдим производителността в реалния свят с реални числа.

В следващата част ще разгледаме действителната производителност на огледалните vdev и RAIDz пулове в сравнение един с друг, а също и в сравнение с традиционните RAID топологии на ядрото на Linux, които разгледахме по-рано.

Първоначално искахме да покрием само основите - самите ZFS топологии - но след това това Ще бъдем готови да говорим за по-разширена конфигурация и настройка на ZFS, включително използването на спомагателни типове vdev като L2ARC, SLOG и Special Allocation.

Източник: www.habr.com