Тази пролет вече обсъдихме някои въводни теми, например, и . Във втората от тях дори обещахме да продължим да изследваме производителността на различни многодискови топологии в ZFS. Това е файловата система от следващо поколение, която в момента се внедрява навсякъде: от до .
Както и да е, днес е най-подходящият ден за запознаване с ZFS, любопитни читатели. Просто знайте, че по скромна оценка от разработчика на OpenZFS Мат Арънс, "това наистина е сложно."
Но преди да стигнем до цифрите — а те ще дойдат, обещавам — относно всички варианти на осемдискова конфигурация ZFS, трябва да говорим за това, как как ZFS всъщност съхранява данните на диска.
Zpool, vdev и device
Тази диаграма на пълния пул включва три помощни vdev’а, по един от всеки клас и четири за RAIDz2
Обикновено няма причина да се създава пул от несъответстващи типове и размери vdev — но, ако искате, нищо не ви пречи да го направите.
За да разберете наистина файловата система ZFS, трябва да погледнете внимателно нейната фактическа структура. Първо, ZFS комбинира традиционните нива на управление на томове и файловата система. На второ място, тя използва механизма на транзакционното копиране при запис. Тези особености означават, че системата структурно се различава много от обикновените файлови системи и RAID масиви. Първият набор от основни строителни блокове за разбиране: това е хранилищния пул (zpool), виртуално устройство (vdev) и реално устройство (device).
zpool
Хранилищният пул zpool — най-горната структура на ZFS. Всеки пул съдържа едно или повече виртуални устройства. От своя страна, всяко от тях съдържа едно или повече реални устройства (device). Виртуалните пулове са автономни блокове. Един физически компютър може да съдържа два или повече отделни пула, но всеки е напълно независим от другите. Пуловете не могат да споделят виртуални устройства.
Излишъкът на ZFS е на ниво виртуални устройства, а не на ниво пулове. На ниво пулове няма абсолютно никаква излишност — ако се загуби някой носител vdev или специален vdev, то с него се губи и целият пул.
Съвременните хранилища могат да преживеят загуба на кеш или журнал на виртуалното устройство — макар и да могат да загубят незначително количество замърсени данни, ако загубят журнала на vdev по време на изключване на захранването или срив на системата.
Има разпространено заблуждение, че "линеите за данни" (страйповете) на ZFS се записват през целия пул. Това не е вярно. Zpool не е просто RAID0, той е по-скоро забавен с усложнен променлив механизъм на разпределение.
До голяма степен записите се разпределят между наличните виртуални устройства в съответствие с наличното свободно пространство, така че теоретично всички те ще бъдат запълнени едновременно. В по-късните версии на ZFS се взема предвид текущото използване (утилизацията) на vdev — ако едно виртуално устройство е значително по-натоварено от друго (например, поради натоварване при четене), то временно ще бъде пропуснато за запис, въпреки наличието на най-високия коефициент на свободно пространство.
Механизмът за определяне на утилизацията, вграден в съвременните методи за разпределение на записи на ZFS, може да намали закъснението и да увеличи пропускната способност през периоди на необичайно висока натовареност — но това не е карт-бланш за случайно смесване на бавни HDD и бързи SSD в едно хранилище. Такова неравностойно хранилище все пак ще работи с бързината на най-бавния уред, т.е. все едно е изцяло съставено от такива устройства.
vdev
Всяко хранилище се състои от едно или повече виртуални устройства (virtual device, vdev). От своя страна, всеки vdev включва едно или повече реални устройства. Повечето виртуални устройства се използват за просто съхранение на данни, но съществуват и няколко помощни класа vdev, включително CACHE, LOG и SPECIAL. Всеки от тези типове vdev може да има една от петте топологии: единично устройство (single-device), RAIDz1, RAIDz2, RAIDz3 или огледало (mirror).
RAIDz1, RAIDz2 и RAIDz3 са специални разновидности на това, което по-старите поколения биха нарекли RAID с двойна (диагонална) паритет. 1, 2 и 3 се отнасят до броя на блоковете паритет, определени за всяка лента с данни. Вместо отделни дискове за осигуряване на паритет, виртуалните устройства RAIDz равномерно разпределят този паритет по дисковете. Масивът RAIDz може да загуби толкова дискове, колкото има блокове паритет; ако загуби още един, той ще се провали и ще отнеме с себе си хранилищния пул.
В огледалните виртуални устройства (mirror vdev) всеки блок се съхранява на всяко устройство в vdev. Въпреки че най-разпространените двойни огледала (two-wide) са често срещани, в огледалото може да има произволен брой устройства — в по-големи инсталации, за повишаване на производителността на четене и отказоустойчивост, често се използват тройни. Огледалото vdev може да преживее всякакъв провал, стига поне едно устройство в vdev да продължава да работи.
Самостоятелните vdev по същността си са опасни. Такова виртуално устройство не ще оцелее при никакъв провал — и ако се използва като хранилище или специален vdev, то провалът му ще доведе до унищожаване на целия пул. Бъдете много, много внимателни тук.
Виртуалните устройства CACHE, LOG и SPECIAL могат да бъдат създадени по която и да е от горепосочените топологии — но запомнете, че загубата на виртуално устройство SPECIAL означава загуба на пула, затова е силно препоръчително да се използва излишна топология.
device
Вероятно това е най-простият за разбиране термин в ZFS — буквално е блочно устройство с произволен достъп. Запомнете, че виртуалните устройства се състоят от отделни устройства, а пулът е изграден от виртуални устройства.
Дисковете — магнитни или твърдотелни — са най-разпространените блочни устройства, които се използват като строителни блокове за vdev. Въпреки това, всяко устройство с дескриптор в /dev е подходящо — така че цели хардуерни RAID масиви могат да бъдат използвани като отделни устройства.
Простият raw файл е едно от най-важните алтернативни блочни устройства, от които може да бъде построен vdev. Тестовите пулове от са много удобен начин за тестване на команди на пула и виждане на наличното пространство в пула или виртуалното устройство на дадената топология.
Можете да създадете тестов пул от разредени файлове само за няколко секунди — но не забравяйте след това да изтриете целия пул и неговите компоненти.
Да предположим, че искате да инсталирате сървър на осем диска и планирате да използвате дискове по 10 ТБ (~9300 ГиБ) — но не сте сигурни коя топология най-добре отговаря на вашите нужди. В горепосочения пример строим тестов пул от разредени файлове за броени секунди — и сега знаем, че RAIDz2 vdev от осем диска по 10 ТБ осигурява 50 ТиБ полезна вместимост.
Друг специален клас устройства е SPARE (резервни). Устройствата с гореща смяна, за разлика от обикновените устройства, принадлежат на целия пул, а не на едно виртуално устройство. Ако някое vdev в пулa се провали, а резервното устройство е свързано към пула и е налично, то автоматично ще се присъедини към дефектния vdev.
След свързването към дефектния vdev, резервното устройство започва да получава копия или реконструкции на данните, които трябва да бъдат на липсващото устройство. В традиционния RAID това се нарича възстановяване (rebuilding), а в ZFS – "възстановяване на излишъка" (resilvering).
Важно е да се отбележи, че резервните устройства не заменят постоянно дефектните устройства. Те са само временно решение за намаляване на времето, през което vdev е в състояние на деградация. След като администраторът замени дефектното устройство vdev, се извършва възстановяване на излишъка върху това постоянно устройство, а SPARE се отделя от vdev и се връща обратно за работа като резервно за целия пул.
Набори от данни, блокове и сектори
Следващият набор от строителни блокове, които трябва да разберем в нашето пътешествие из ZFS, се отнася не толкова до хардуера, а до начина, по който са организирани и съхранявани самите данни. Пропускаме няколко нива — като metaslab — за да не натоварваме детайлите, запазвайки разбирането на общата структура.
Набор от данни (dataset)
Когато за първи път създадем набор от данни, той показва цялото налично пространство на пула. След това задаваме квота — и променяме точката на монтиране. Магия!
Zvol е по същество просто набор от данни, лишен от своя слой на файлова система, който тук заменяме с напълно нормална файлова система ext4.
Наборът от данни ZFS е приблизително аналогичен на стандартната монтирана файлова система. Както при обикновената файлова система, той изглежда 'просто още една папка'. Но, както е при обикновените монтирани файлова системи, всеки набор от данни ZFS има свой собствен набор от основни свойства.
Преди всичко, на набора от данни може да бъде зададена квота. Ако зададете zfs set quota=100G poolname/datasetname, няма да можете да запишете в монтираната папка /poolname/datasetname повече от 100 ГиБ.
Забелязахте ли наличието — и отсъствието — на наклонените черти в началото на всяка линия? Всеки набор от данни има свое място както в иерархията на 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.
В допълнение към наборите от данни, трябва да споменем обемите (zvols). Обемът е приблизително аналогичен на набора от данни, с изключение на това, че в него всъщност няма файлова система — това е просто блоково устройство. Можете, например, да създадете zvol с името mypool/myzvol, след което да го форматирате с файлова система ext4, а след това да монтирате тази файлова система — сега имате файлова система ext4, но с поддръжка на всички функции за сигурност на ZFS! Това може да изглежда глупаво на един компютър, но има много повече смисъл като бекенд при експортиране на iSCSI устройство.
Блоковете
Файлът е представен от един или няколко блока. Всеки блок се съхранява на едно виртуално устройство. Размерът на блока обикновено е равен на параметъра recordsize, но може да бъде намален до 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 КиБ означава, че е необходимо първо да се запише "сектора", след това да се прочете секторът от 4 КиБ, да се промени с втория 512-байтов "сектор", да се запише обратно в новия сектор от 4 КиБ и така нататък за всяко записване.
В реалния свят такъв глобус удря твърдотелните дискове Samsung EVO, за които трябва да важи ashift=13, но тези SSD лъжат за размера на сектора си, и следователно по подразбиране се задава ashift=9. Ако опитен системен администратор не промени този параметър, този SSD работи по-бавно от обикновен магнитен HDD.
За сравнение, за твърде голям размер ashift практически няма глобус. Няма реално намаляване на производителността, а увеличението на неизползваното пространство е безкрайно малко (или нула при включено компресиране). Следователно горещо препоръчваме дори на тези дискове, които наистина използват 512-байтови сектори, да установят ashift=12 или дори ashift=13, за да се уверите, че гледате уверено в бъдещето.
Свойство ashift се задава за всяко виртуално устройство vdev, а не за пула, както много погрешно мислят — и не се променя след установяване. Ако случайно сбъркате ashift при добавяне на нов vdev в пула, сте необратимо замърсили този пул с устройство с ниска производителност и обикновено няма друга опция, освен да унищожите пула и да започнете отначало. Дори премахването на vdev няма да спаси от сбърканите настройки. ashift!
Механизъм за копиране при запис
Ако обикновената файлова система трябва да презапише данни — тя променя всеки блок там, където се намира.
Файлова система с копиране при запис записва нова версия на блока и след това отключва старата версия.
В абстрактен вид, ако игнорираме реалното физическо разположение на блоковете, нашата "комета от данни" се опростява до "червей от данни", който се движи отляво надясно по картата на наличното пространство.
Сега можем да получим добро разбиране как работят моментните снимки при копиране при запис — всеки блок може да принадлежи на няколко моментни снимки и ще се запази, докато всички свързани моментни снимки не бъдат унищожени.
Механизмът на копиране при запис (Copy on Write, CoW) е основната основа на това, което прави ZFS толкова невероятна система. Основната концепция е проста — ако поискате от традиционна файлова система да промени файл, тя ще направи точно това, което сте искали. Ако поискате от файлова система с копиране при запис да направи същото, тя ще каже "добре" — но ще ви излъже.
Вместо това, файлова система с копиране при запис записва нова версия на изменен блок и след това актуализира метаданните на файла, за да разъсни връзката със стария блок и да го свърже с новия блок, който току-що записахте.
Изключването на стария блок и свързването на новия се извършва в една операция, така че не може да бъде прекратена — ако изключите тока след това, имате нова версия на файла, а ако изключите тока по-рано, имате стара версия. Във всеки случай конфликти в файловата система няма да се появят.
Копирането при запис в ZFS се осъществява не само на ниво файлова система, но и на ниво управление на дисковете. Това означава, че ZFS не е подложена на пробив в запис () — феномен, при който лента е успяла само частично да запише информация преди системен срив, с повреда на масива след рестартиране. Тук лентата се записва атомарно, vdev винаги е последователен, и .
ZIL: журнал на намеренията на ZFS.
Системата ZFS обработва синхронни записи по особен начин — временно, но незабавно ги запазва в ZIL, преди по-късно да ги запише окончателно заедно с асинхронни записи.
Обикновено данните, записани в ZIL, повече никога не се четат. Но това е възможно след системен срив.
SLOG, или вторично LOG устройство, е просто специален - и за предпочитане много бърз - vdev, където ZIL може да се съхранява отделно от основното хранилище.
След срив всичките замърсени данни в ZIL се възстановяват - в този случай ZIL е на SLOG, така че те се възстановяват точно оттам.
Съществуват две основни категории операции по запис - синхронни (sync) и асинхронни (async). За повечето работни натоварвания подавляващото мнозинство операции по запис са асинхронни - файловата система позволява да се агрегира тях и да се издават на пакети, намалявайки фрагментацията и значително увеличавайки пропускната способност.
Синхронните записи са съвсем различна работа. Когато приложението изисква синхронен запис, то казва на файловата система: "Трябва да го запишеш в енергонезависимата памет в момента", а дотогава не мога да направя нищо друго." Затова синхронните записи трябва да бъдат незабавно фиксирани на диска - и ако това увеличава фрагментацията или намалява пропускната способност, така да бъде.
ZFS обработва синхронните записи по различен начин от обикновените файлови системи - вместо да ги налива незабавно в обикновеното хранилище, ZFS ги записва в специална зона за съхранение, наречена журнал на намеренията ZFS - ZFS Intent Log, или ZIL. Хитростта е, че тези записи също остават в паметта, агрегирани заедно с обикновените асинхронни заявки за запис, за да бъдат по-късно записани в хранилището като напълно нормални TXG (групи транзакции, Transaction Groups).
В нормален режим на работа ZIL се записва и никога повече не се чете. Когато след няколко мигове записите от ZIL бъдат фиксирани в основното хранилище в обикновените TXG от оперативната памет, те се отделят от 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 ГиБ и включваше 126 927 файла. Това е доста близо до оптималната ситуация за rsync - репликацията на ZFS по мрежата беше "само" с 750% по-бърза.
В същата мрежа репликацията на 40-гигабайтов файл на образ на виртуална машина Windows 7 е съвсем различна история. Репликацията ZFS става 289 пъти по-бързо от rsync – или "само" 161 пъти по-бързо, ако сте достатъчно запознати, за да извикате rsync с ключа –inplace.
Когато образът на виртуалната машина се мащабира, проблемите с rsync също се мащабират. Размерът от 1,9 ТиБ не е толкова голям за съвременен образ на виртуална машина, но е достатъчно голям, за да установим, че репликацията 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 КиБ, а на това място на диска е резервиран само един сектор.
При ZFS няма такъв проблем, тъй като променените записи винаги се записват в неизползваното пространство – оригиналният блок заема само един сектор от 4 КиБ, а новият запис ще заеме 256, но това не е проблем – наскоро промененият фрагмент от „средата“ на файла ще бъде записан в неизползваното пространство, независимо дали е променил размера си или не, така че за ZFS това е напълно нормална ситуация.
Вградената компресия на ZFS е изключена по подразбиране, а системата предлага включваеми алгоритми – в момента те са LZ4, gzip (1-9), LZJB и ZLE.
- LZ4 – това е потоков алгоритъм, предлагащ изключително бърза компресия и декомпресия и подобряване на производителността за повечето случаи на използване – дори и на доста бавни CPU.
- GZIP – реномиран алгоритъм, който всички потребители на Unix системи познават и обичат. Може да бъде реализиран с нива на компресия 1-9, с увеличаване на степента на компресия и използване на CPU, когато се приближавате до ниво 9. Алгоритъмът е подходящ за всички текстови (или други силно компресируеми) варианти на използване, но в противен случай често причинява проблеми с CPU – използвайте го с внимание, особено на по-високи нива.
- LZJB – оригиналният алгоритъм в ZFS. Той е остарял и вече не трябва да се използва, LZ4 го превъзхожда във всички аспекти.
- ZLE — кодировка на нулево ниво, Zero Level Encoding. Тя изобщо не засяга нормалните данни, но компресира големи последователности от нули. Полезно е за напълно неконпресируеми набори от данни (например, JPEG, MP4 или други вече компресирани формати), тъй като игнорира неконпресируеми данни, но компресира неизползваното пространство в крайния запис.
Препоръчваме компресия LZ4 практически за всички случаи на употреба; наказанието за производителността при среща с неконпресируеми данни е много малко, а прибавката на производителността за типични данни е значителна. Копирането на образа на виртуалната машина за нова инсталация на операционна система Windows (свежо инсталирана ОС, без данни вътре още) с compression=lz4 протече с 27% по-бързо, отколкото с compression=none, в .
ARC — адаптивна замяна на кеша
ZFS — това е единствената известна ни съвременна файлова система, която използва собствен механизъм за кеширане на четене, а не разчита на кеша на страниците на операционната система за съхраняване на копия на наскоро прочетени блокове в оперативната памет.
Въпреки че собственото кеширане не е лишено от проблеми — ZFS не може да реагира на нови заявки за разпределение на паметта толкова бързо, колкото ядрото, така че новото извикване malloc() за разпределение на паметта може да се провали, ако му е необходима оперативна памет, заета в момента от ARC. Но има основателни причини да се използва собственото кеширане, поне за сега.
Всички известни съвременни ОС, включително MacOS, Windows, Linux и BSD, за реализация на кеша на страниците използват алгоритъма LRU (Least Recently Used). Това е примитивен алгоритъм, който повдига кеширания блок "нагоре в опашката" след всяко четене и изтласква блоковете "надолу в опашката" по необходимост, за да добави нови пропуски от кеша (блокове, които трябваше да бъдат прочетени от диска, а не от кеша) нагоре.
Обикновено алгоритъмът работи добре, но в системи с големи работни набори от данни LRU лесно води до трэшинг — изтласкване на често необходими блокове, за да се освободи място за блокове, които никога повече няма да бъдат прочетени от кеша.
— значително по-малко наивен алгоритъм, който може да се разглежда като "теглен" кеш. След всяко прочитане на кеширания блок, той става малко "по-тежък" и е по-трудно да бъде изместен — и дори след изместване блокът се проследява в продължение на определен период от време. Блок, който е бил изместен, но след това трябва да бъде прочетен обратно в кеша, също ще стане "по-тежък".
Крайната цел на всичко това е кеш с много по-висок коефициент на попадане (hit ratio) — съотношението между попаденията в кеша (четене, извършвано от кеша) и пропуските (четене от диска). Това е изключително важна статистика — не само, че самите попадения в кеша се обслужват многократно по-бързо, пропуските в кеша също могат да се обслужват по-бързо, тъй като колкото повече попадения в кеша — толкова по-малко паралелни заявки към диска и толкова по-малко забавяне за останалите пропуски, които трябва да се обслужват от диска.
Заключение
След изучаване на основната семантика на ZFS — как работи копирането при запис, а също и отношенията между хранилищните пулове, виртуалните устройства, блоковете, секторите и файловете, — сме готови да обсъдим действителната производителност с реални числа.
В следващата част ще разгледаме фактическата производителност на пуловете с огледални vdev и RAIDz, един в сравнение с друг, както и в сравнение с традиционните RAID топологии на ядрото на Linux, които проучвахме .
Първоначално искахме да разгледаме само основите — самите топологии на ZFS — но след такова ще сме готови да обсъдим по-напреднала настройка и настройка на ZFS, включително използването на помощни типове vdev, като L2ARC, SLOG и Special Allocation.
Източник: habr.com
