c o p y r i g h t p r o g r a m m i n g d e s i g n e d by ZORBI
Т р о и ц к г
С с ы л к и
С ч е т ч и к и
..:: Статьи ::..
Обзор журналируемых файловых систем под Linux
Введение
Компьютер работает с данными в виде нулей и единиц, которые записаны на жестком диске. Без файловой системы невозможно разобраться со всей этой кашей - непонятно, где начало, а где конец нужных нам данных. Поэтому, как только появились магнитные носители, записанные на них данные стали объединять в файлы. В принципе, из одного байта уже можно сформировать файл. Знаешь, как к компьютерам подключались магнитофоны и данные записывались на обычную кассету? Это пример неиерархической файловой системы: файлы располагались на кассете последовательно. Чтобы перейти к нужному файлу, нужно было перемотать ленту.
К тому времени, как появились гибкие и жесткие диски, неиерархическая файловая система стала совсем неэффективной. Во-первых, операции чтения, записи и поиска были слишком медленными даже по меркам тех времен. Во-вторых, количество файлов возросло, и стало неудобно держать их все в одном каталоге. В-третьих, на имена файлов накладывались ограничения, и существовала опасность, что все возможные варианты названий исчерпаются и создать новый файл будет нельзя. Правда, вероятность этого события была слишком мала.
С учетом всех этих проблем были созданы иерархические файловые системы, позволяющие объединять файлы в каталоги, а также хранить подкаталоги в каталогах. В начале fs находится таблица размещения файлов, в ко¬торой прописаны физические координаты частей файла. Теперь файлы записываются не последовательно, поэтому обойтись начальным адресом и смещением относительно него уже нельзя: файловая система должна помнить, где находится каждая часть файла.
Теперь разберемся, что такое целостность файловой системы. Файловую систему мож¬но считать целостной, если один блок дан¬ных принадлежит одному и только одному файлу, то есть изменение одного файла или каталога не приводит к изменению другого файла или каталога. Иногда при проверке файловой системы в Windows обнаруживается, что кластеры пересекаются, то есть один кластер принадлежит двум или более файлам сразу. Обычно такие файлы нужно удалять, хотя есть возможность обрезать файл до момента коллизии, чтобы сохранить хоть какую-то часть информации. В случае с текстовыми файлами это помогает - хоть что-то, да и останется, а вот двоичные файлы можно удалять сразу.
В начале каждой файловой системы есть так называемый чистый бит. При монтировании файловой системы бит «clean» стирается - это означает, что файловая система используется в данный момент, а при размонтировании, наоборот, устанавливается. Если при загрузке ОС обнаруживает, что чистый бит не установлен, она запускает средство проверки файловой системы (в *nix это программа fsck, а в Windows - scandisk). Программа проверки проверяет не что иное, как целостность файловой системы.
время записи программой какого-то файла, пусть и очень важного. Файл можно восста¬новить хотя бы частично. А вот если свет пропал, когда операционная система запи¬сывала метаданные файловой системы, то есть сведения про саму fs, то ты можешь не досчитаться не одного, а, скажем, ста фай¬лов или даже больше.Когда же чистый бит не может быть установлен? Обычно тому есть две причины: отключение питания компьютера или перезагрузка Reset’ом, что приравнивается к отключению питания, и сбой программы (это больше касается Windows) или даже ядра (тоже больше подходит для Windows, но может случиться с любой ОС) операционной системы, что приводит к зависанию компьютера.
Целостность файловой системы может быть нарушена, если программа или сама ОС записывала данные на диск и в этот момент произошло отключение питания. Хорошо, если отключение питания произошло во время записи программой какого-то файла, пусть и очень важного. Файл можно восстановить хотя бы частично. А вот если свет пропал, когда операционная система записывала метаданные файловой системы, то есть сведения про саму fs, то ты можешь не досчитаться не одного, а, скажем, ста файлов или даже больше.
Файловые системы
Представим такую ситуацию. У нас есть жесткий диск на 80 Гб. Сегодня таким объемом никого не удивишь, не так ли? Мы поленились разбить его на разделы, и у нас есть один большой раздел на 80 Гб. В момент записи на диск произошло отключение питания. При загрузке операционная система запустит средство проверки диска. Представляешь, сколько времени займет такая проверка? Даже при условии, что ошибок будет мало или вообще не будет, придется ждать довольно долго. А если будет нарушена целостность, то ее восстановление займет еще несколько минут твоего драгоценного времени. Все это справедливо для обычной файловой системы.
А как же работает журналируемая файловая система? Если обычная fs просто выполняет запланированные команды, то журналируемая перед тем, как что-то сделать, записывает стратегический план действий, например скопировать файл file.txt в файл report.txt, а затем удалить файл file.txt. Записывается этот план в специальный файл, который называется журналом. Как только журналируемая файловая система убедится, что пункт ее плана полностью выполнен и данные успешно записаны на диск, она вычеркивает этот пункт из журнала. Если что-то она выполнить не успела, а ты, например, отключил питание, то при следующем запуске программа проверки файловой системы будет проверять не все данные на диске, а только те файлы, которые есть в журнале, ведь остальные данные не причем, а ошибки если и будут, то в файлах, которые записаться не успели.
Почему ошибок может и не быть? Обрати внимание, что запись в журнал ведется ДО начала самой работы с диском. Операция, записанная в журнал, может еще и не начаться, а питание уже пропадет. Благодаря этому даже вероятность ошибок в файловой системе значительно снижается, хотя... Лучше, чем ИБП (UPS), средства от отключения питания пока никто не придумал.
Другими словами, журналируемая файловая система - это файловая система, устойчивая к сбоям. Основными журналируемыми файловыми системами на сегодняшний день являются XFS, ReiserFS, JFS и Ext3. Сначала я расскажу о первых трех, а о ext3 мы поговорим в последнюю очередь, поскольку она заслуживает особого внимания в силу того, что является стандартной файловой системой Linux.
Файловая система XFS
Первая версия XFS была выпущена компанией Silicon Graphics (SGI) 1 мая 2001 года. XFS была разработана для IRIX 5.3. Особенностями данной файловой системы являются поддержка очень больших дисков и высокая скорость ввода/вывода (до 7 Гб/с). Использование данной файловой системы имеет смысл, если ты работаешь с видео в реальном времени. При использовании XFS можно установить размер блока от 512 байт до 64 Кб. Как правило, если у тебя много маленьких файлов, устанавливается наименьший размер блока. Так можно сэкономить дисковое пространство. Если тебе приходится работать с файлами больших размеров (с тем же видео), целесообразно установить наибольший размер блока - так повысится производительность и уменьшится фрагментация.
Файловая система ReiserFS
Основной особенностью ReiserFS является способность хранить несколько мелких файлов в одном блоке. Данная особенность на¬зывается Tail Packing. Tail (хвост) - это небольшие файлы, размер которых меньше логического блока, или остатки более крупных файлов. Размер блока фиксирован и составляет 4 Кб. В силу этого данную fs нужно использовать, если у тебя много небольших файлов, поскольку маленький размер блока негативно влияет на скорость операций ввода/вывода с большими файлами. И еще: если ReiserFS сильно фрагментирована, работать она будет очень медленно. Относительно защиты от сбоев, ReiserFS тоже слаба: в случае сбоя (например выключения питания) данные, находившиеся в используемых во время сбоя блоках, могут быть повреждены. ReiserFS не гарантирует сохранность данных во время сбоя.
Файловая система JFS
JFS была разработана компанией IBM для AIX 3.1, позднее была перенесена на OS/2, а не так давно и под Linux. Размер журнала составляет примерно 40% от размера fs. Максимальный размер равен 32 Pb (1 Pb = 10^15 b). Эта файловая система может содержать несколько сегментов, содержащих журнал и данные. Эти сегменты называются агрегатами и могут монтироваться отдельно. Основные особенности JFS: довольно большая производительность (даже несколько больше, чем у XFS) и надежность (еще бы -ведь она разрабатывалась для серверов!).
JFS использует интересный режим работы журнала: на момент возвращения успешного результата изменения метаданных файловой системы результаты выполняемых операций уже записаны и останутся в журнале, даже если сбой произошел сразу же после выполнения операции.
Что же касается размера блоков, то можно выбрать любой из четырех стандартных размеров в зависимости от потребностей: 512, 1024, 2048 и 4096 байт. Конечно, 4 Кб - это не 64 Кб, как в случае с XFS, и для работы с видео будет маловато, но ведь серверы для этого используются довольно редко.
Файловая система ext3
С момента своего появления ext3 уверенно набирала обороты, и если, скажем, года два назад никто бы не рискнул установить на сервер новую файловую систему, то сейчас она используется в большинстве случаев - программы установки практически всех дистрибутивов предлагают ext3 по умолчанию. Некоторые источники сообщают, что ext3 - это всего лишь надстройка над ext2, а не самостоятельная файловая система. В этом утверждении есть доля правды, так как ext3 совместима со всеми программами для обслуживания и настройки ext2.
А кто быстрее?
Тестировать производительность рассматриваемых файловых систем сам я не стал - в Сети уж очень много проведенных тестов, нужно только найти подходящий. Как раз только установил панель поиска Google Toolbar, и выпала возможность испытать ее. Ввожу Ext2, Ext3, ReiserFS, XFS and JFS benchmarks, на что Google вернул довольно много ссылок, одна из них oregonstate.edu/~kveton/fs/page1.php. На этой страничке описывается тестирование ext2, ext3 во всех режимах журнала, JFS и ReiserFS в разных режимах для больших и маленьких файлов. Жаль, что тестировалось все на ядрах 2.4 и 2.5, а не 2.4 и 2.6, поэтому комментировать буду только ядро 2.4 (2.5 установлено далеко не у всех).
Ориентироваться будем на загрузку CPU, ведь это решающий фактор при определении быстродействия системы - чем выше загрузка CPU, тем вероятнее система будет тормозить. При условии последовательного блочного вывода (Sequential Output, Block) минимальную нагрузку на процессор дает ext2 (13%), но поскольку она не журналируемая, то ее к особому вниманию не принимаем. Среди журналируемых файловых систем лидером по самой низкой загрузке CPU стала JFS (14%). При минимальной загрузке процессора JFS еще и достаточно быстра - 47178 Кб/с. По быстродействию в этом режиме она лидер (ext2 мы договорились не считать). На втором месте по быстродействию - ReiserFS - 46640 Кб/с, также эта файловая система на втором месте и по загрузке процессора - 24%. Ext3 досталось третье место. Однако не спеши с умозаключениями. Работа файловой системы не ограничивается последовательным блочным выводом, есть еще и другие режимы.
К сожалению, размер статьи не позволяет прокомментировать все режимы, поэтому сразу перейдем к маленьким файлам. Будем рассматривать последовательный блочный ввод. По загрузке процессора и по производительности картина та же: на первом месте JFS, затем ReiserFS, потом ext3.
Не могу удержаться, чтобы не прокомментировать результаты для ядра 2.5.65 - это уже почти 2.6. Для работы с большими файлами я бы выбрал JFS. По производительности она лидирует, давая 49510 Кб/с, а по загрузке процессора не сильно отличается от XFS и все той же ext2 - 14% против 13%. При работе с маленькими файлами опять лидер JFS: 49343 Кб/с и 14% против 46727 Кб/с и 13% у XFS. Осталось добавить, что тестирование проводилось с помощью Bonnie++. Скорее всего, другие программы покажут иные результаты. Дополнительные условия и конфигурацию тестируемой системы можно узнать по адресу: http://oregonstate.edu/~kveton/fs/page1.php.
