 |
|
|
|
Файловые системы Linux
Файловые системы Linux Что мне нравится в OС GNU/Linux, так это гибкость во всем, практически можно собрать систему под определенные задачи, выбрав необходимое из множества компонентов. Кроме патчей к ядру, различных версий библиотек и компиляторов, есть возможность выбора и файловой системы, на которой будет работать ОС. В данной статье я предлагаю пробежаться по многообразию и определиться с выбором, узнать о достоинствах и недостатках предлагаемых файловых систем. Под файловой системой понимается физический способ организации данных на дисковом разделе, т.е. возможность их хранения, нахождения и манипулирования ими (запись, стирание). Думаю, такого простенького определения вполне достаточно, чтобы понять, какие требования выдвигаются к файловой системе. До недавнего времени в Linux предлагалась для использования фактически только одна файловая система ext2fs. Да, возможно было, конечно, и установить ее в раздел FAT, но занятие это кажется мне крайне нездоровым, да и производительность и стабильность при таком размещении только страдает. Также изначально в ядре поддерживается возможность взаимодействовать с файловыми системами других ОС, расположенных на одном диске. Их можно посмотреть, набрав: #make xconfig и зайдя в пункт меню File system, все я их перечислять не буду, для включения их поддержки ядром его необходимо иногда пересобрать, активировав необходимый пункт. Да и то для наиболее распространенных, таких как NTFS Windows NT и UFS (FFS) FreeBSD, запись в них помечена как DANGEROUS, плюс еще не забыта даже MINIX (стоит ли говорить о позавчерашнем дне). Но сейчас предлагаемый ассортимент несколько увеличился, в современных ядрах добавилась возможность работы с так называемыми журналируемыми файловыми системами – ext3fs, ReiserFS, XFS и JFS. Не говоря уж о поддержке технологий Soft-RAID и LVM. Но и это еще не все, для тех, кому нужна повышенная конфиденциальность информации, хранимой на компьютере, вполне подойдет CFS, свободная криптографическая файловая система от Матта Блейза (Mutt Blaze) для UNIX/Linux (http://www.crypto.com/software) или TCFS (Transparent Cryptographic File System) (http://www.tcfs.it). В данной статье будут рассмотрены только классические файловые системы как наиболее часто применяемые на компьютерах, об остальных поговорим как-нибудь отдельно в следующий раз. Итак, по старшинству. Ext2fs Как уже говорилось, данная файловая система в Linux – это уже стандарт де-факто, ее характеризует довольно высокая надежность и самое высокое из рассматриваемых файловых систем быстродействие, которые в свою очередь достигаются дублированием особо важных метаданных и очень эффективным механизмом кэширования дисковых операций. Но так как Linux используется все чаще и чаще на высокопроизводительных серверах, то она уже не удовлетворяет обычным требованиям – большие разделы жесткого диска, быстрое восстановление после сбоев, высокопроизводительные операции ввода/вывода, потребность в хранении тысяч и тысяч файлов, представляющих терабайты данных. Все это уже превышает возможности данной файловой системы. Еще одной особенностью этой файловой системы является тройная косвенная адресация для указания расположения блоков больших файлов. Выглядит это примерно так. Вся информация о расположении блоков данных, принадлежащих данному файлу, хранится в inode. Если файл маленький, то в его метаданных хватает места для размещения нужной информации, и туда помещаются прямые ссылки на ячейки (логические блоки), в которых хранятся данные, – прямая адресация. При увеличении же объема файла, так как отведенное место уже не может адресовать занимаемое пространство, то блоки метаданных указывают уже на косвенные блоки, в которых содержатся адреса с данными, определенными в файле (простая косвенная адресация), или опять же указатели на следующие косвенные блоки (тройная косвенная адресация). То есть если файл увеличивается в размере и для пользователя это проходит как единичная операция, внутри выглядит несколько иначе: поначалу распределяются новые блоки, для того чтобы содержать новые данные, затем модифицируется inode, чтобы сделать запись о новых указателях и новых размерах, а затем, в конце концов, производится запись данных. Вот теперь представьте, что будет, если при записи файла произойдет сбой. Возможно несколько вариантов. Например, запись уже произведена или еще не начиналась – это самый оптимистичный вариант, в первом случае после перезагрузки вы так и будете работать с документом, ничего не заметив, а во втором случае просто теряется пара часов работы, но с файловой системой ничего такого страшного не произойдет. А вот если система «упала» именно в момент сохранения файла, то это худшее из того, что могло произойти. Если запись производилась в зону метаданных, то теперь информация, содержащаяся в них, не будет соответствовать реальному расположению файлов на диске. Ситуация несколько усугубляется еще и тем, что Linux, в отличие от Windows, не обязательно записывает обновленный файл поверх старого, при записи во избежание фрагментации выбирается место, чтобы он влез полностью и на соседние блоки. Поэтому-то в этой системе нет программ дефрагментаторов, мне доводилось видеть фрагментацию данных максимум 1-2 %, да и то на переполненном диске, что, согласитесь, очень мало (вообще на переполненных дисковых разделах существенно падает скорость операций IO, что характерно для всех UNIX-файловых систем). Так вот, а если данные заносились в каталог (а ведь это тоже файл), то после перезагрузки мы можем недосчитаться одного каталога или, что хуже, вообще целого раздела. Ну а если произошел сбой при записи в область данных, то, что он будет потом содержать, зависит от вашего везения, особенно в случае, если производилась запись поверх старого варианта файла. Конечно, ситуация не так плачевна, как я обрисовал. За то время, что я активно эксплуатирую систему, и пройдя вместе с ней не одно выключение электропитания, случаев из ряда вон выходящих не было. Естественно, чтобы избежать такое рассогласование, для данной файловой системы были разработаны утилиты, помогающие восстановить ее после сбоев. За несколько лет их алгоритм, в отличие от всеми любимого Scandisk, не поленились довести практически до совершенства. Так как проверять при каждой перезагрузке все диски, установленные на компьютере, согласитесь, накладно по времени, нашли такой простой выход. После того как все данные согласованы, непосредственно перед самым ее размонтированием устанавливается бит чистого размонтирования – clean bit (в Windows также используется аналогичная технология). И перед загрузкой системы перед ее монтированием программа fsck (FileSystem ChecK) просто проверяет его наличие, если бит установлен, то делается вполне разумное предположение, что файловая система находится в непротиворечивом состоянии, а если нет, то запускается изрядно всем надоевшая утилита fsck. В связи с тем, что ext2fs создает избыточные копии критически важных метаданных, вероятность полной потери данных чрезвычайно мала, система определяет местонахождение поврежденных метаданных и потом либо восстанавливает данные, копируя их из резервных копий, либо просто удаляет файл или файлы, чьи метаданные пострадали. Точнее, не удаляет, а переносит их в каталог /lost+found. Правда, в большинстве дистрибутивов и определение корректности завершения работы также немного упростили. Так, чтобы не гонять fsck индивидуально для каждого раздела, при включении компьютера стартовыми скриптами проверяется наличие файла /.autofsck, который должен удаляться в /etc/rc.d/init.d/halt. Его наличие указывает на некорректность выключения питания, и fsck отрабатывает по полной программе, а если такой файл не обнаруживается, то делается вполне справедливое предположение о нормальном завершении работы, и диски проверяются по минимуму, тем самым ускоряя загрузку системы. Но вот не всегда удается нормально завершить работу, и fsck отрывается, что говорится, по полной программе. Вот тут-то и кроется очевидное неудобство, согласитесь, что чем больше файловая система, тем дольше длится процесс проверки. На дисковом разделе размером в несколько десятков гигабайт, что давно уже перестало быть редкостью и тенденция к увеличению размеров разделов только растет, с большим количеством файлов и каталогов процедура проверки метаданных во время загрузки может очень сильно затянуться. Может, для домашнего компьютера это всего лишь раздражает пользователя (сколько отказываются от проверки Scandisk при загрузке, а потом удивляются, почему в свойствах неправильно указано свободное пространство). А вот если выбило главный производственный сервер и теперь пользователи вынуждены ждать, пока он перегрузится? Вот так плавно человечество подошло к журналируемым файловым системам. Напоследок скажу, что сейчас имеет смысл использовать ext2 только в разделе /boot, который обычно автоматически не монтируется при загрузке, запись в него производится довольно редко, и особого смысла держать журнал нет. Что такое журнал? Все колдовство журнала заключается в механизме транзакций, термин известен тем, кто работал с базами данных. Точно так же, как и в них, механизм транзакций вместо отслеживания модификаций к таблицам и данным рассматривает операцию записи на диск как атомарную, а не разделенную на несколько этапов, что позволяет отследить, прошла ли запись вообще, и в свою очередь гарантировать, что все или ни одно изменение файловой системы не сделано. Поясню сказанное на примере. При создании нового файла изменяются несколько структур метаданных (inodes, списки свободных блоков, список файлов каталога и др.). Прежде чем файловая система сделает изменения, создается транзакция, в которой описывается то, что она собирается сделать. Как только транзакция будет зарегистрирована (на диске), файловая система приступает непосредственно к изменению метаданных. То есть фактически журнал в journaling-файловой системе – просто список производимых операций. В случае системного сбоя файловая система будет восстановлена к непротиворечивому состоянию путем повторного запуска журнала и отката к предыдущему состоянию. К тому же в таком случае файловая система осматривает только те участки диска, в которых изменялись метаданные, т.е. она уже «знает», на каком участке произошел сбой. Это намного быстрее, чем при традиционной проверке всего диска при помощи fsck. И что самое существенное, время восстановления, получается, совсем не зависит от размера раздела, а скорее зависит от интенсивности операций ввода/вывода на момент сбоя. Можно выделить два возможных варианта работы журналируемой файловой системы. В первом варианте в журнал заносятся только изменяемые метаданные файла, в таком случае при сбое будет гарантирована целостность метаструктур файловой системы, а сохранность самих данных уже зависит от везучести. Второй вариант предусматривает занесение в журнал вместе с метаданными также и самих данных, как изменившихся, так и немодифицированных, в этом случае есть вероятность, что данные после сбоя будут восстановлены. И конечно же, «природу не обманешь, за все нужно платить». А платить теперь приходится быстродействием, так как самая медленная операция в компьютере – это операции ввода/вывода на диск, количество таких операций выросло, особенно при использовании варианта с полным журналированием данных. Стараются решить данную проблему разными ухищрениями, например, размещение журнала на другом физическом диске. Да и потери невелики, ведь фактически время работы с журналом намного меньше, чем работа непосредственно с данными. И естественно, некоторый полезный объем теперь приходится отводить под сам журнал, но он, как правило, не занимает места больше 32 Мб, что по нынешним временам не так уж и много. Самый главный вывод такой: журналируемые файловые системы предназначены не для восстановления всех ваших данных любой ценой, главная их задача заключается в поддержании непротиворечивости метаданных файловой системы на момент сбоя и ускорения процесса загрузки системы после сбоя. Также в большинстве современных journaling-файловых систем поддерживаются:
Старая методика прямого, косвенного и тройного косвенного механизма хранения информации о нахождении данных файла очень неудобна при работе с файлами большого размера по причине долгого поиска информации и в современных файловых системах заменена на более удобную, позволяющую работать с большими файлами «напрямую». Кроме того, некоторые новые файловые системы имеют более совершенный механизм управления внутренней фрагментацией (что это такое, объясню чуть позже) и распределения 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 имеет три режима работы:
Выбранный режим, отличный от установленного по умолчанию, необходимо указать с помощью опции -o. Например: #mount -o data=journal -t ext3 /dev/hda5 /usr/local или в /etc/fstab: /dev/hda5 /usr/local ext3 data=writeback 1 0 или если режим по умолчанию, то просто: /dev/hda5 /usr/local ext3 defaults 1 0 Если же теперь хочется отказаться от него, то, исправив ext3 на ext2, можно забыть о журнале: /dev/hda5 /usr/local ext2 defaults 1 0 Для того чтобы к обычной ext2fs добавить журнал, достаточно выполнить команду: # /sbin/tune2fs -j /dev/hdа5 причем можно даже файловую систему не размонтировать перед этим, так как гарантируется сохранность данных (но предварительная архивация данных никому еще не вредила). Для того чтобы изначально создать ext3 на пустом, только что созданном разделе диска, достаточно выполнить команду: # /sbin/mke2fs -j /dev/hdb5 Начиная с версии 0.9.5 ext3fs, можно использовать другой диск для хранения файла журнала. Подробности можно узнать по адресу http://www.zipworld.com.au/~akpm/linux/ext3/ext3-usage.html. Вот и все о данной файловой системе. Что и говорить, это предсказуемая и главное – удобная файловая система. До недавнего времени добрая половина разделов жесткого диска на моем домашнем компьютере была отформатирована именно под ext3, но эксперименты с латентностью ядра при обработке музыки убедили, что пора с ней красиво расставаться (хотя доводилось слышать и полностью противоположное мнение). Плюс у нее есть еще недостаток, доставшийся по наследству, который практически полностью решен в другой файловой системе. Но интересно, что в дистрибутивах RedHat программа установки, несмотря на наличие стольких альтернатив, позволяет создать только ext2 и ext3, хотя ядро поддерживает JFS и RaiserFS. Что это – упорное продвижение своей файловой системы или нежелание идти в ногу с прогрессом? ReiserFS Это первая «сторонняя» файловая система, появившаяся в официальном ядре, начиная с версии 2.4.4, но в первое время ее работа вызывала одни только нарекания, и поэтому использовали ее только любители острых ощущений. Данный проект начинался в 90-х годах, первый прототип носил название TreeFS. Разработана Хансом Райзером (Hans Reiser) и его компанией Namesys (http://www.namesys.com), причем задачи они перед собой поставили очень, я бы сказал, революционные. Разработчики системы мечтают создать не только файловую систему, но вообще механизм иерархического именования объектов. Они считают, что лучшая файловая система та, которая формирует единую общедоступную среду, названную namespace. Для достижения этого файловая система должна выполнять часть работы, традиционно выполнявшуюся приложениями, что уменьшит количество несовместимых API узкоспециального назначения. При таком подходе пользователи часто могут продолжать прямое использование файловой системы вместо формирования уровней специального назначения типа баз данных и т. п. Правда, надо отметить, что они не первые, еще при создании BeFS первоначально это было сделано, и с большим успехом, работа filesystem как базы данных, но в конечном счете вернулись назад к атрибутам и индексированному доступу. Некоторое движение в этом направлении сделано и в MacOS. При этом для добавления новых возможностей используется plugins. А вообще на сайте проекта наилучшая документация из всех рассматриваемых. Но предупреждаю, ее там много. Базируется файловая система на оптимизированных b* сбалансированных деревьях (одно на файловую систему), использование которых, кроме увеличения поизводительности, снимает ограничение на количество каталогов, хотите – 100 000, без проблем. Но текущая на данный момент версия 3.6 поддерживает журналирование только метаданных, хотя при необходимости полного журналирования можно использовать патч от Chris Mason и дополнительно в новой версии ReiserFS v.4 release, которая будет доступна вместе с ядром 2.6. Также будет задействован подобный режим. Главное преимущество данной файловой системы проявляется в работе с маленькими файлами. Как я уже говорил, информация на физическом носителе хранится не как попало, а отдельными блоками, размер которых зависит и от размера раздела (это связано с максимально возможной адресацией) в том числе (устанавливается при форматировании), в большинстве случаев используется 4 Кб. Так вот, еxt2 (и ext3, и FAT тоже) могут адресовать только целое количество блоков. Ну и что? Имеем файл 10 Кб, размер блока 4 Кб. Получается, что файл займет 2 целых блока и один только наполовину. 4 + 4 + 2 (и 2 осталось незанятыми, это и называется внутренней фрагментацией). Для единичного файла это нестрашно, но если их несколько тысяч? Кстати, Fast File System (FFS), применяемая в BSD, умеет адресовать субблоки, а во всеми любимой FAT придется мириться с неизбежной потерей места. Разработчики ReiserFS не стали решать множество противоречивых задач, а остановились на одной и довели ее до конца. ReiserFS может запросто упаковывать несколько маленьких файлов в один дисковый блок (tail packing), а совсем маленькие вообще просто запихать в inode (внутрь b*tree). По необходимости для файла может ассигноваться точный размер. Такой режим работы предусмотрен по умолчанию, но для повышения быстродействия есть возможность ее отключить. Хотя показатели ReiserFS при работе с большими файлами также высоки, именно работа с маленькими файлами (меньше Кб) и обслуживание большого их количества выделяет данную ФС. По работе с ними она превосходит по быстродействию все представленные файловые системы (видел цифры в 8-15 раз) и именно за счет того, что данные и метаданные хранятся рядом, и головке диска не придется рыскать по всему диску. Плюс, как видите, достигается значительная экономия дискового пространства. Различные источники называют ReiserFS самой устойчивой из всех рассматриваемых ФС, ее, я думаю, можно рекомендовать для корневого раздела, который к тому же состоит из маленьких файлов. Такая себе рабочая лошадка. Но для работы с данной файловой системой, кроме поддержки ее самим ядром, необходимы также свои собственные утилиты для работы и обслуживания разделов, хотя они уже входят в стандартную поставку всех современных дистрибутивов, а если нет, то возьмите по адресу ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.4.tar.gz. Патч к ядру для обновления версии ReiserFS можно взять с ftp://ftp.namesys.com/pub/reiserfs-for-2.4, рядом лежат патчи к ядрам версии 2.2. Если ядро уже поддерживает ReiserFS и имеются необходимые утилиты, то, набрав: # /sbin/mkreiserfs /dev/hda2 можно создать на ней соответствующую файловую систему. Для автоматического монтирования ее при загрузке достаточно прописать в файле /etc/fstab: /dev/hda4 /home reiserfs defaults 0 0 или #/sbin/mount -t /reiserfs dev/hda4 /home при монтировании вручную. Если для увеличения производительности необходимо отключить упаковку хвостов, то добавьте опцию notail: /dev/hda4 /home reiserfs notail 0 0 А опция -genericread может увеличить (а может и нет) производительность при операциях поиска файлов, т.е. когда головка мало считывает, а много перемещается по диску. И, кстати, проект Reiser4, в котором не последнее место уделено security, поддерживается DARPA (Defense Advanced Research Projects Agency). XFS Основа следующей файловой системы XFS была создана в начале 90-х (1992-1993) фирмой Silicon Grapgics (сейчас SGI) для мультимедийных компьютеров с ОС Irix, заменив уже не удовлетворявшую требованиям времени EFS, но немного очищенная от некоторого кода GPL версия 1.0 стала доступна только 1 мая 2001 года. Найти всю необходимую информацию можно по адресу: http://oss.sgi.com/projects/xfs. Интересно, что «любимица» всех линуксоидов, компания SCO, и здесь засветилась, назвав выход XFS под лицензией GPL «примером ярких работ нарушения авторских прав». Эта файловая система с самого начала была ориентирована на очень большие файлы (9 000 петабайт – 9 миллионов терабайт – 1018 байт) и файловые системы (18 000 петабайт ), это достигается тем, что она, в отличие от предыдущих, является полностью 64-битной, что позволяет адресовать большие массивы данных. Особенностью этой файловой системы является устройство журнала – в него пишется часть метаданных самой файловой системы таким образом, что весь процесс восстановления сводится к копированию этих данных из журнала в файловую систему. Размер журнала задается при создании системы, он должен быть не меньше 32 Мб; а больше, наверное, и не надо – такое количество незакрытых транзакций тяжело получить. Тесты на производительность показывают бесспорное преимущество XFS, особенно при работе с большими и во многих случаях средними файлами. Также эту файловую систему характеризует прямолинейность падения производительности при увеличении нагрузки и предсказуемость, дополнительно она не генерирует излишнюю дисковую активность, т.к. пытается кэшировать как можно больше данных и «основанием» для сброса на диск является заполнение памяти, а не интервал времени, как это принято в других файловых системах (кроме, наверное, ReiserFS v4). Любое дисковое устройство при создании файловой системы XFS разбивается на несколько равных по размеру линейных областей (0.5-4 Гб), в терминологии XFS они именуются «allocation group». Уникальность allocation group в том, что каждая группа управляет своими собственными inodes и свободным местом, что превращает группы в своего рода автономные файловые системы, сосуществующие в рамках общей XFS. Такая организация позволяет эффективно организовать параллельную обработку операций ввода/вывода, которая особенно проявляется на многопроцессорных системах. В каждой такой группе используется три В+ дерева, два из которых отвечают за свободные inodes (allocation). В этой системе реализована очень хорошая возможность, позволяющая избежать фрагментации файлов, называемая delayed allocation. При этом файловая система, получая данные для записи, поначалу лишь резервирует под них необходимое свободное место, откладывая саму запись до момента фактического сброса данных. Когда же такой момент наступает, то XFS решает, куда необходимо их поместить. Если осуществляется дозапись, то подбираются соседние сектора. Но наибольший эффект в такой задержке получается еще за счет того, что, если создается временный файл с малым временем жизни, то он вообще при таком случае на диск не пишется (соответственно не приходится занимать/освобождать метаданные). Для борьбы с внешней фрагментацией (против которой борятся программы типа Norton Speed Disk) имеется утилита xfs_fsr. Текущим ядром серии 2.4.* данная файловая система не поддерживается (но уже имеется в тестовых ядрах 2.6), хотя в некоторых дистрибутивах (Gentoo, Lunar Linux) она уже предлагается пользователю, поэтому необходимо сходить на сайт разработчика за патчем (ftp://oss.sgi.com/projects/xfs/download) и необходимыми утилитами (как миниум xfsprogs) для работы с ней. Сейчас на сайте доступен релиз 1.3. Теперь, пересобрав ядро и установив необходимые утилиты, можно создать файловую систему: #/sbin/mkfs.xfs /dev/hdb2 или mkfs -t xfs /dev/hdb2 Для увеличения производительности в некоторых случаях может помочь опция -l size=32m, фиксирующая журнал на 32 Мб, и с помощью -d agcount=x лучше установить минимально возможное количество allocation groups (т.е. взяв максимально возможные 4 Гб на группу), например, при разделе 18 Гб устанавливаем: #/sbin/mkfs.xfs -d agcount=5 -l size=32m -f /dev/hdb2 Необязательная опция -f позволяет создать XFS поверх любой существующей ФС, но при создании раздела поверх ReiserFS (и наоборот) необходимо заполнить нулями начальный раздел, содержащий метаданные перед переформатированием, т.к. команда mount может неправильно распознать, какая из файловых систем установлена. # dd if=/dev/zero of=/dev/hdb2 И прервать секунд через 10-20 комбинацией Ctr+C. Смонтировать вновь созданный раздел теперь можно командой: # mount -t xfs =/dev/hdb2 /home или в файле /etc/fstab: /dev/hdb2 /home xfs defaults 0 0 Для повышения производительности можно задать некоторые опции noatime, nodiratime, osyncisdsync, вместе помогающие добиться асинхронного вывода информации, и практически имитировать поведение ext2, а также logbufs, устанавливающий размер буфера, имеющий значение по умолчанию, равное 2 (но, например, 8 при 128 Мб оперативной памяти устанавливать не стоит). /dev/hdb2 /home xfs noatime, nodiratime, osyncisdsync, logbufs=4 0 0 Еще в документе Linux XFS FAQ, доступном на сайте разработчика, сказано, что на данный момент загрузка с раздела XFS поддерживается полностью загрузчиком GRUB версий 0.92 и выше, LILO же позволяет загружаться только при установке в MBR (Master Boot Record), при установке в корневой раздел есть вероятность, что загрузиться не получится. В CVS доступны утилиты xfsdump и xfsrestore, позволяющие сохранить и при необходимости восстановить образ раздела диска. Остальную информацию посмотрите в каталоге /usr/src/linux/Documentation/filesystems xfs.txt. Как установить XFS в корневой раздел, можно посмотреть в документе Linux+XFS-HOWTO (http://www.linuxdoc.org/HOWTO/Linux+XFS-HOWTO). JFS (Journaled File System) Создана фирмой IBM для своей OS/2 Warp, а затем выпущена по лицензии GPL и портирована под Linux. Всю необходимую информацию можно получить по адресу http://oss.software.ibm.com/jfs. По своим характеристикам и архитектуре очень схожа с предыдущей, поэтому подробно останавливаться на них не буду. Подобно предыдущей в этой файловой системе раздел логически подразделяется на «агрегаты», включающие, кроме данных, и отдельный журнал, и каждый из таких сегментов можно монтировать отдельно. Также имеется возможность хранения маленьких файлов в пределах inode. Если каталог имеет до 8 файлов, то информация о них содержится внутри inode, при увеличении же их количества используются уже знакомые B+ деревья. Для уcтановки необходимы утилита jfsutils, патч к ядру jfs-2.4.х-patch и код файловой системы jfs-2.4-1.0.20.tar.gz, хотя вероятно, что поддержка данной файловой системы в ядре уже имеется. После установки и компиляции всех программ для создания раздела достаточно выполнить команду: # mkfs.jfs /dev/hdb3 и смонтировать ее: # mount -t jfs /dev/hdb3 /jfs Для возможности работы с внешним журналом необходимо создать два неиспользуемых раздела, например: # mkfs.jfs -j /dev/hdb1 /dev/hda6 # mount -t jfs /dev/hda6 /jfs или в /etc/fstab: /dev/hda6 /jfs jfs defaults 1 2 Напоследок хочу отметить, что все описываемые файловые системы на данный момент поддерживают установку на Soft-RAID и LVM, при наложении соответствующих патчей возможно применение ACL. Как видите, ОС Linux предоставляет пользователю возможность выбрать даже файловую систему, оптимизированную под конкретные задачи. И самое главное, не обязательно, чтобы была установлена только одна из этих файловых систем. Но вот однозначно сказать, что такая файловая система намного лучше, я не могу. Как вы понимаете, все зависит от конкретной задачи, ведь приложения, которые используются на сервере, могут отличаться. Но для раздела /boot лучшим решением будет ext2, для корневого раздела, состоящего из мелких файлов – ReiserFS. Для сравнения приведу результат теста Linux: Benchmarking Filesystems In 2.6.0-test2, найденный мной на странице http://kerneltrap.org/node/view/715. Там же можно найти и мнения различных людей по поводу полученных результатов. При записи и копировании каталога (mozilla build tree) размером 295 Мб файловые системы показали такой результат, который, я думаю, в комментариях не нуждается.
Литература:
|
СЕРГЕЙ ЯРЕМЧУК, Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
