Библиотека сайта rus-linux.net
Как разделяют пингвинов
Сергей А. ЯРЕМЧУК Grinder@ua.fm
"Мой Компьютер" #9(232)/03.03.2003.
Продолжение, начало см. в МК # 8 (231).В прошлой части статьи мы рассмотрели вопросы, связанные так или иначе с дисковыми разделами: их обозначение, рекомендуемое количество и инструменты, предназначенные для их создания. Но создать раздел на диске мало ≈ для того чтобы можно было разместить на нем данные, необходимо позаботиться о создании на нем файловой системы.
Файловые системы: что посеешь, то пожнешь
Под файловой системой понимается, физический способ организации данных на дисковом разделе ≈ возможность их хранения, нахождения и манипулирования ими (запись, стирание). Я думаю, такого простенького определения достаточно, чтобы понять, какие требования выдвигаются к ФС. До недавнего времени в Linux к услугам пользователей предлагалась только одна ФС ≈ ext2fs, предоставлявшая возможность взаимодействовать с ФС других ОС, расположенных на одном диске. Посмотреть перечень таких ФС можно, набрав #make xconfig и зайдя в пункт меню File system. Для включения поддержки их ядром последнее необходимо пересобрать, активировав необходимый пункт. В современных ядрах Linux добавилась возможность работы с различными журналируемыми файловыми системами: ext3fs, ReiserFS, XFS и JFS. Для тех же, кому нужна более гибкая в конфигурировании и быстродействующая файловая система, появилась возможность создавать программные RAID-массивы (раздел raid auto, идентификатор fd) и системы управления логическими томами (LVM, идентификатор 8e). Кроме того, те, кому нужна повышенная конфиденциальность информации, хранимой на компьютере, могут воспользоваться CFS, свободной криптографической файловой системой для Unix/Linux от Матта Блейза (Mutt Blaze). В этой и последующих статьях будут рассмотрены только классические файловые системы, чаще всего применяемые на ПК.
Она была первой: Ext2fs
Как уже говорилось, данная ФС в Linux ≈ это уже стандарт де-факто, ее характеризует довольно высокая надежность и самое высокое из рассматриваемых ФС быстродействие, которое в свою очередь достигается очень эффективным механизмом кэширования дисковых операций. Но так как Linux все чаще используется на высокопроизводительных серверах, то ext2fs уже не удовлетворяет их требованиям ≈ необходимы большие разделы жесткого диска, быстрое восстановление после сбоев, высокопроизводительные операции ввода/вывода, потребность в хранении тысяч и тысяч файлов, представляющих терабайты данных. Все это превышает возможности данной ФС.
Еще одной ее особенностью является тройная косвенная адресация для указания расположения блоков больших файлов. Выглядит это примерно так. Если файл маленький, то в его метаданных содержится прямая ссылка на ячейки, в которых хранятся данные (логические блоки). Это прямая адресация. При увеличении же объема файла до некоторой критической величины занимаемое им место не удается адресовать с помощью прямой адресации. Блоки метаданных указывают уже на косвенные блоки, в которых содержатся адреса с данными, определенными в файле, или опять же указатели на следующие косвенные блоки. Количество таких косвенных блоков для одного файла может достигать трех. То есть если файл увеличивается в размере, внешне это выглядит как единичная операция, внутри же несколько иначе: поначалу распределяются новые блоки, чтобы принять новые данные, затем модифицируется inode, чтобы сделать запись о новых указателях и новых размерах, затем наконец производится запись данных.
Вот теперь представьте, что будет, если при записи файла произойдет сбой. Возможен вариант, когда запись уже произведена или еще не начиналась. Это самый благоприятный вариант: в первом случае после перезагрузки вы так и будете работать с документом, ну а во втором случае потеряется пару часов работы, но с файловой системой ничего страшного не произойдет. А вот если система "упала" именно в момент сохранения файла, то это худшее из того, что могло произойти. Если запись производилась в зону метаданных, то теперь информация, содержащаяся в них, не будет соответствовать реальному расположению файлов на диске. Ситуация усугубляется еще и тем, что Linux, в отличие от Windows, не обязательно записывает обновленный файл поверх старого ≈ при записи во избежание фрагментации выбирается такое место, чтобы он влез полностью. Потому-то в этой системе нет программ-дефрагментаторов (мне доводилось наблюдать фрагментацию данных максимум 0.5%, да и то на переполненном диске, что, согласитесь, очень мало). Так вот, если данные заносились в каталог ≈ а ведь это тоже файл, ≈ то после перезагрузки мы можем недосчитаться одного каталога или, что еще хуже, целого раздела. Ну а если произошел сбой при записи в область данных, то что он будет потом содержать, зависит от вашего везения, особенно в случае, если производилась запись поверх старого варианта файла. Конечно, ситуация не так плачевна, как я обрисовал. За все время активной эксплуатации системы, пережив вместе с ней не одно выключение электропитания, случаев, из ряда вон выходящих, не было (тук-тук-тук).
Естественно, для данной файловой системы (это я все еще о ext2fs веду речь) были разработаны утилиты, помогающие восстановить ее после сбоев. За несколько лет их алгоритм, в отличие, от всеми любимого Scandisk'a, не поленились довести до почти совершенства. Так как проверять при каждой перезагрузке все диски, установленные на компьютере, согласитесь, накладно по времени, нашли такой простой выход. После того как все данные согласованы, непосредственно перед самым ее размонтированием устанавливается clean bit (в Windows также используется аналогичная технология). Перед загрузкой системы перед ее монтированием программа fsck (FileSystem ChecK) просто проверяет его наличие; если бит установлен, то делается вполне разумное предположение, что файловая система находится в непротиворечивом состоянии, а если нет, то запускается изрядно всем надоевшая утилита fsck (scandisk, по-Microsoft'овски). В связи с тем, что ext2fs содержит избыточные копии критически важных метаданных, вероятность полной потери данных чрезвычайно мала. Система определяет местонахождение поврежденных метаданных и потом либо восстанавливает данные, копируя их из резервных копий, либо просто удаляет файл или файлы, чьи метаданные пострадали. Точнее, не удаляет, а переносит их в каталог /lost+found. В этом-то и состоит очевидное неудобство: согласитесь, что чем больше файловая система, тем дольше длится процесс проверки. На дисковом разделе размером в несколько гигабайт, что давно уже перестало быть редкостью, с большим количеством файлов и каталогов, процедура проверки метаданных во время загрузки может очень сильно затянуться. А если выбило главный производственный сервер, и теперь пользователи вынуждены ждать, пока он перегрузится? Вот так мы плавно подошли к журналируемым файловым системам.
Что есть журнал?
Вся волшебная сила журнала заключена в механизме транкзаций ≈ этот термин неплохо известен тем, кто работал с базами данных. Как и там, механизм транкзаций вместо отслеживания модификаций к таблицам и данным, рассматривает операцию записи на диск как атомарную, а не разделенную на несколько этапов, что позволяет отследить, прошла ли запись вообще, и в свою очередь гарантировать, что изменение файловой системы произведено полностью или не произведено вообще. Поясню сказанное на примере. Например, при создании нового файла изменяются несколько структур метаданных (inodes, списки свободных блоков, список файлов каталога и др.) Прежде, чем в файловой системе произойдут изменения, создается транзакция, в которой описывается то, что должно быть сделано. Как только транзакция будет зарегистрирована (на диске), файловая система приступает непосредственно к изменению метаданных. То есть фактически журнал в такой файловой системе ≈ просто список производимых операций. В случае системного сбоя файловая система будет восстановлена к непротиворечивому состоянию путем повторного запуска журнала и отката к предыдущему состоянию. К тому же в таком случае файловая система осматривает только те участки диска, в которых изменялись метаданные, т.е. она уже "знает", где произошел сбой. Это намного быстрее, чем при традиционной проверке с помощью fsck. И что самое существенное, время восстановления совсем не зависит от размера раздела ≈ скорее, от интенсивности операций на момент сбоя.
Можно выделить два возможных варианта работы журналируемой файловой системы. В первом варианте в журнал заносятся только изменяемые метаданные файла, в таком случае при сбое будет гарантированы метаструктуры файловой системы, а сохранность самих данных уже зависит от везучести. Второй вариант предусматривает занесение в журнал вместе с метаданными также и самих данных, как изменившихся, так и не модифицированных, в этом случае есть вероятность, что данные после сбоя будут восстановлены. И конечно же, как говорил мой преподаватель по теоретическим основам электроцепей, "природу не обманешь, за все нужно платить", а платить теперь приходиться быстродействием, так как самые медленные операции в компьютере ≈ это операции ввода/вывода на диск, а количество таких операций возросло, особенно при использовании варианта с журналированием данных. Решают вопрос разными ухищрениями: например, запись происходит в момент наименьшей активности, некоторые журналируемые файловые системы позволяют разместить журнал на другом физическом диске. Да и фактически время работы с журналом намного меньше, чем работа непосредственно с данными. И естественно, некоторый полезный объем теперь приходится отводить под сам журнал, но его размеры как правило не превышают 32 Мб, что по нынешним временам не так уж и много.
Самое главное, что вы должны запомнить: журналируемые файловые системы предназначены не для восстановления всех ваших данных любой ценой, главная их задача заключается в поддержании непротиворечивости метаданных файловой системы на момент сбоя.
Большинство современных journaling файловых систем поддерживают:
более быстрое распределение свободных блоков; для этого большинство из них построено на основе сбалансированных деревьев, иначе известных как B+ деревья. О том, что это такое, лучше спросите у авторов, пишущих о различных языках программирования, особенно об алгоритмах поиска и сравнения, а особо любопытные пусть посмотрят документ по адресу http://starship.python.net/crew/aaron_watters/bplustree/bplustree.py.txt;
большее количество файлов в каталоге: поскольку обычная связка name-inode становится неэффективной, то опять же для хранения имен файлов используются B+ деревья. В некоторых случаях возможно использование всего одного B+ дерева для полной системы, что намного укорачивает поиск файла и, соответственно, операции по работе с ним. Плюс динамическое выделение inides вместо неэффективного статического;
старая методика прямого, косвенного т.д. механизма хранения информации о нахождении данных файла, очень неудобная при работе с файлами большого размера по причине долгого поиска информации, заменена на более гибкую, позволяющую работать с большими файлами "напрямую";
кроме того, некоторые новые файловые системы имеют более совершенный механизм управления внутренней фрагментацией (что это такое, объясню чуть ниже) и распределения inodes, чем Ext2. Может, конечно, сложиться впечатление, что место журналируемым файловым системам ≈ где-нибудь на сервере; нет, они подходят на все сто процентов для использования на клиентских машинах, везде где есть необходимость в сохранении данных. Теперь, когда мы точно знаем, что ожидать от описываемых файловых систем, перейдем к их конкретной реализации.
Система в красной шапке: Ext3fs
Хотя данная файловая система не была первой, поддерживаемой ядром Linux официально (появилась только с версии 2.4.16), все таки я думаю, что справедливо будет начать именно с нее. Разработана она в недрах компании Red Hat (там и следует искать всю информацию о ее работе) доктором Стефеном Твиди (Stephen Tweedie). Найти патчи для ядра можно по адресу ftp://ftp.linux.org.uk/pub/linux/sct/fs/jfs. Чтобы не изобретать колесо, поступили просто, прикрутив к стандартной ext2fs журнал (в зависимости от опций монтирования, его можно и не видеть; находится в ./.journal) и заменив драйвер ядра, отвечающий за файловую систему. По этой причине она, естественно, наследует все достоинства и недостатки, присущие ext2fs . Но что это дало?
Самое главное ≈ это то, что утилиты ext2fs, которые шлифовались в течение нескольких лет, работают в ней как ни в чем не бывало. К тому же идентичность файловых систем позволяет оперативно переходить как с еxt3fs на ext2fs, так и наоборот. Поясню. Мне часто приходится устанавливать другие дистрибутивы, в том числе и со старыми ядрами, не поддерживающими новинку. Так вот, все разделы, на которых используется ext3fs, я монтирую просто как ext2fs ≈ и никаких, повторяю, никаких недоразумений при использовании не происходит.
Другое преимущество данной файловой системы состоит в том, что она, в отличие от остальных, поддерживает режим журналирования данных (полное или частичное). Естественно, добавление журнала, казалось бы, должно было ухудшить производительность такой системы по сравнению с "нежурнальным" вариантом. Оказалось, что за счет улучшения алгоритма движения головки жесткого диска данная файловая система в некоторых случаях даже обходит ext2fs. Ext3fs имеет три режима работы:
data=writeback ≈ режим, при котором не выполняется никакого журналирования данных, учитываются только метаданные ≈ самый ограниченный режим журналирования (кстати, применяемый во всех других ФС рассматриваемых ниже), не гарантирующий сохранности данных после сбоя. Но за счет этого возрастает скорость работы такой файловой системы: фактически журнал предназначен только для того, чтобы уменьшить время начальной загрузки системы;
по умолчанию же используется data=ordered ≈ золотая середина между полным журналированием данных и предыдущим режимом. Официально в этом случае журналируются только метаданные, но блоки соответствующих им данных записываются первыми. В большинстве случаев такой режим гарантирует сохранность данных, особенно если данные дописывались в конец файла, чего в большинстве случаев предостаточно. Производительность, естественно, чуть ниже предыдущей и выше
режима полного журналирования ≈ data=journal, ≈ в котором все новые данные сначала пишутся в журнал и только после этого переносятся на свое законное место. В случае аварийного отказа журнал можно повторно перечитать, приведя данные и метаданные в непротиворечивое состояние. Кстати, как оказалось, данный режим в случае, когда диск интенсивно загружен операциями IO, оказывается даже быстрее всех остальных.
Выбрав режим, отличный от установленного по умолчанию, необходимо указать его с помощью опции -o. Например:
Или в /etc/fstab:
Если же теперь захочется отказаться от него, то, исправив ext3 на ext2, можно забыть о журнале:
Для того чтобы к обычной ext2fs добавить журнал, достаточно выполнить команду
причем на неразмонтированной файловой системе. При этом вроде как гарантируется сохранность данных, хоть предварительно заархивировать их все же не повредит. Для того чтобы изначально создать ext3 на пустом только что созданном разделе диска, достаточно выполнить команду:
Начиная с версии 0.9.5, ext3fs может использовать другой диск для хранения файла журнала. Подробности можно узнать по адресу http://www.zipworld.com.au/~akpm/linux/ext3/ext3-usage.html.
Вот и все о данной файловой системе. От себя хочу заметить, что разделы /home, /usr/local, которые часто приходится монтировать к другим Linuxам, у меня отформатированы именно под ext3. Что и говорить, это предсказуемая и, главное, УДОБНАЯ файловая система. Характеристики относительно максимального количества файлов и каталогов, а также максимальных размеров разделов меня полностью устраивают. Но у нее есть один наследственный недостаток, который практически полностью решен в другой ФС. Но об этом поговорим чуть позже.
(Продолжение следует)