Желаем на всички отлични почивни дни! Каним ви на безплатен демо-урок , който ще води Андрей Буранов — специалист по UNIX системи в компанията Mail.Ru Group. Публикуваме и статия от Джонатан Корбет — изпълнителен редактор в LWN.net.
Журналируемите файлови системи обещават да освободят системните администратори от проблеми с повреждането на дискове при системни сривове. Дори без да стартират проверка на целостта на файловата система. Въпреки това в реалността всичко е малко по-сложно. И както показа последната дискусия, може би дори по-заплетено, отколкото мнозина от нас мислят, тъй като осигуряването на целостта на журналируемите файлови системи влияе на производителността.
Файлова система като ext3 използва отделна област на диска, наречена журнал. Когато се извършват промени в метаданните на файловата система, тези промени първо се записват в журнала без модификация на останалата част от файловата система. След записването на всички промени в журнала, в него се добавя „комит блок“, който указва завършването на транзакцията. И едва след записването на комит блока, транзакцията се фиксира, а променените метаданни се записват на диска. Ако системата се срине в някакъв момент, информацията в журнала може безопасно да завърши операцията и да предотврати повреди на файловата система, защото само част от метаданните е актуализирана.
Но има едно уловка: кодът на файловата система преди записването на комит блока трябва да бъде абсолютно сигурен, че цялата информация за транзакцията вече е попаднала в журнала. Просто записването на операциите в правилен ред не е достатъчно — съвременните дискове поддържат големи вътрешни кешове и пренареждат операциите за подобряване на производителността. Следователно преди комит блока е необходимо експлицитно да се укаже прехвърлянето на всички данни от журнала на диска. Ако комит блокът бъде записан по-рано, журналът може да бъде повреден. За решаване на този проблем се използват бариери. По същество, бариерата забранява записването на всякакви блокове след бариерата, докато всички блокове, записани преди бариерата, не бъдат прехвърлени на диска. Използвайки бариери, файловите системи гарантират последователността на файловите структури.
Но има още една задача: файловите системи ext3 и ext4 по подразбиране не използват бариери. Опцията е налична, но ако администраторът не я активира изрично, тези файлови системи работят без бариери, макар в някои дистрибуции (например, SUSE) подразбиращите се стойности да са различни. Ерик Сандин (Eric Sandeen) наскоро реши, че трябва да се направи нещо по този въпрос и , който модифицира подразбиращите се настройки за ext3 и ext4. И тогава започна оживена дискусия.
Андрю Мортон (Andrew Morton) много подробно , защо подразбиращата се стойност е точно такава:
В миналото, когато се опитахме да променим това, производителността при много натоварвания спадна с 30%, затова в ужас изхвърлих всичките тези пачове. Мисля, че не можем да си позволим да забавим работата на всички машини толкова сериозно...
Тук няма идеални решения, и съм склонен да не будя тази спяща кучка и да оставя параметрите по подразбиране на съвестта на разработчиците на дистрибуции.
Така че, по подразбиране бариерите са деактивирани, тъй като те сериозно влияят на производителността. Освен това, файловите системи успешно се използват и без бариери. Съобщенията за повреда на файловата система ext3 са малкочислени и редки.
Но това не е просто късмет. Тед Цо (Ted Ts’o) това с факта, че журналът ext3 / ext4 обикновено е разположен непрекъснато. Първо, драйверът на файловата система се опитва да го направи непрекъснат. Второ, журналът обикновено се създава едновременно с файловата система, когато е лесно да се намери непрекъснато пространство. Непрекъснатостта и редът са полезни не само за производителността, но и за предотвратяване на преордоняване. Обикновено комит блокът ще бъде разположен веднага след останалите данни в журнала, така че дискът няма причина за преордоняване. Комит блокът естествено се записва на диска веднага след останалите записи в журнала.
Въпреки това, никой не твърди, че това ще е винаги така. Дисковите устройства могат да функционират и по различен начин. Освен това, журналът представлява цикличен буфер. Следователно, когато транзакцията бъде записана в края на журнала, блокът на комита може да се окаже в по-ранен блок, преди други записи в журнала. Така че рискът от повреда винаги съществува. Всъщност, Крис Мейсън има за това . Няма съмнение, че работата без бариери е по-малко безопасна, отколкото с тях.
Ако сте готови да приемете удар по производителността, можете да включите бариерите. В този случай, разбира се, ако вашата файлова система не е на базата на LVM (както в някои дистрибуции по подразбиране). Оказва се, че устройството за картографиране не поддържа бариери. В останалите случаи би било добре да се намали понижението на производителността. И, изглежда, това е възможно.
Текущата реализация на ext3 (когато бариерите са включени) изпълнява следната последователност от операции за всяка транзакция:
Данните се записват в журнала
Изпълнява се бариера
Записва се комит блок
Изпълнява се следваща бариера
По-късно метаданните се изпразват на диска
В ext4 първата бариера (стъпка 2) може да бъде пропусната, тъй като файлова система ext4 поддържа контролни суми в журнала.
Ако данните от журнала и комит блокът са пренаредени, а операцията е прекъсната в резултат на повреда, контролната сума на журнала няма да съвпада с тази, която се съхранява в комит блока, и транзакцията ще бъде отхвърлена.
Крис Мейсън , че би било "по принцип безопасно" да се премахне тази бариера и в ext3, с възможно изключение, когато журналът достигне края и започне да се записва отначало.
Още една идея за ускоряване на работата е да се отложат операциите с бариери, когато това е възможно. Ако няма належаща нужда веднага да се изпразнят данните на диска, може да се създадат няколко транзакции в журнала и да се изпразнят на диска с една бариера.
Също така има известен потенциал за подобрение чрез внимателно подреждане на операциите, така че бариерите (които обикновено се реализират като заявки "изпразни всички отложени операции на диска") да не принуждават до запис на блокове, които не изискват подреденост.
Изглежда, че е време да помислим как да направим цената на бариерите приемлива. Тед Цо, изглежда, :
Смятам, че трябва да включим бариери в ext3/4 и след това да работим върху намаляване на разходите в ext4/jbd2. Най-вероятно подавляващото мнозинство от системите не работят при условия, подобни на тези, които Крис използва за демонстрация на проблема, и сигурността на файловата система по подразбиране трябва да бъде приоритет.
Здравият разум ми казва, че тази кучка вече не спи и вероятно ще лае известно време. Това може да предизвика безпокойство у някои съседи, но е по-добре, отколкото да я оставим да ухапе.
Интересно ли е да се развивате в тази посока? Запишете се за безплатен демонстрационен урок и участвайте в предаването , който ще води Павел Викирюк — оператор на MVNO, DevOps инженер.
Източник: habr.com
