Под файловой системой понимается, физический способ организации данных на дисковом разделе, т.е. возможность их хранения, нахождения и манипулирования (запись, стирание). Первое время в Linux предлагалась для использования только одна файловая система ext2fs, можно конечно и установить ее в раздел FAT (например на flash), но производительность и стабильность при таком размещении только страдает. Изначально в ядре поддерживается возможность взаимодействовать с файловыми системами других ОС, расположенных на одном диске. Их можно посмотреть набрав make xconfig и зайти в пункт меню File system. Для включения поддержки их ядром, его необходимо иногда пересобрать активировав необходимый пункт. Да и то для наиболее распространенных, таких как NTFS и UFS (FFS) FreeBSD запись в них помечена как DANGEROUS. В современных же ядрах добавилась возможность работы с различными журналируемыми файловыми системами (ext3, ReiserFS (с патчами даже Reiaser 4), XFS и JFS). Для тех же кому нужна более быстродействующая или гибкая в конфигурировании файловые системы, появилась возможность создавать программные RAID-массивы (раздел raid auto, идентификатор fd), и системы управления логическими томами (LVM) (идентификатор 8e). Кроме того, для тех кому нужна повышенная конфиденциальность информации хранимой на компьютере может воспользоваться CFS, свободной криптографической файловой системой от Матта Блейза (Mutt Blaze) для Unix/Linux (http://www.crypto.com/software/) была еще TCFS, но сайт что-то давно не отзывается. Далее будут рассмотрены только классические файловые системы, как наиболее часто применяемые на ПК. И так по старшинству.
Ext2fs
            Данная файловая система в Linux это уже стандарт де-факто, ее характеризует довольно высокая надежность и самое высокое из рассматриваемых ФС быстродействие, которое в свою очередь достигается очень эффективным механизмом кэширования дисковых операций, но так как Linux уже используется все чаще и чаще на высокопроизводительных серверах, то она уже не удовлетворяет обычным требованиям – большие разделы жесткого диска, быстрое восстановление после сбоев, высокопроизводительные операции ввода/вывода, потребность в хранении тысяч и тысяч файлов, представляющих терабайты данных. Все это уже превышает возможности данной файловой системы. Еще одной особенностью данной файловой системы является тройная косвенная адресация для указания расположения блоков больших файлов. Выглядит это примерно так если файл маленький, то в его метаданных содержится прямая ссылка на ячейки (логические блоки) в которых хранятся данные – прямая адресация. При увеличении же объема файла так как отведенное место уже не может адресовать занимаемое пространство, то блоки метаданных указывают уже на косвенные блоки в которых содержатся адреса с данными определенными в файле или опять же указатели на следующие косвенные блоки и так до утроения. То есть если файл увеличивается в размере и для пользователя выглядит как единичная операция, внутри выглядит несколько иначе: поначалу, распределяются новые блоки для того чтобы содержать новые данные, затем модифицируется inode чтобы сделать запись о новых указателях и новых размерах, а затем, в конце концов, производится запись данных. Вот теперь представьте, что будет, если при записи файла произойдет сбой. Возможен вариант, когда запись уже произведена или еще не начиналась это самый оптимистичный вариант, в первом случае после перезагрузки вы так и будете работать с документом ну, а во втором случае просто теряется пару часов работы, но с файловой системой ничего такого страшного не произойдет. А вот если система «упала» именно в момент сохранения файла. Это худшее из того, что могло произойти. Если запись производилась в зону метаданных, то теперь информация содержащаяся в них не будет соответствовать реальному расположению файлов на диске. Ситуация усугубляется еще и тем что Linux в отличие от Windows не обязательно записывает обновленный файл поверх старого, при записи во избежание фрагментации выбирается место чтобы он влез полностью. Поэтому то в этой системе нет программ дефрагментаторов, мне доводилось видеть фрагментацию данных максиум 0.5 %, да и то на переполненном диске, что согласитесь очень мало. Так вот а если данные заносились в каталог а ведь это тоже файл, то есть после перезагрузки мы можем недосчитаться одного каталога или что хуже целого раздела. Ну а если произошел сбой при записи в область данных, то что он будет потом содержать зависит от вашего везения, особенно в случае если производилась запись поверх старого варианта файла. Конечно ситуация не так плачевна как я обрисовал. За то время что я активно эксплуатирую систему и пройдя в месте с ней не одно выключение электропитания случаев из ряда вон выходящих не было. (тук-тук-тук). Естественно для данной файловой системы (это я еще о Ext2fs веду речь) были разработаны утилиты помогающие восстановить ее после сбоев. За несколько лет их алгоритм в отличие от всеми любимого Scandisk’a не поленились довести почти до совершенства. Так как проверять при каждой перезагрузке все диски установленные на компьютере согласитесь накладно по времени, нашли такой простой выход. После того как все данные согласованы и непосредственно перед самым ее размонтированием устанавливается бит чистого размонтирования – clean bit (в Windows также используется аналогичная технология). И перед загрузкой системы перед ее монтированием программа fsck (FileSystem ChecK) просто проверяет его наличие, если бит установлен то делается вполне разумное предположение, что файловая система находится в непротиворечивом состоянии, а если нет то запускается утилита fsck (scandisk по Microsoft’овски). В связи с тем, что ext2fs содержит избыточные копии критически важных метаданных, вероятность полной потери данных чрезвычайно мала. Система определяет местонахождение поврежденных метаданных и потом либо восстанавливает данные, копируя их из резервных копий, либо просто удаляет файл или файлы, чьи метаданные пострадали. Точнее не удаляет, а переносит их в каталог /lost+found. Вот тут то и кроется очевидное неудобство, согласитесь, что чем больше файловая система, тем дольше длится процесс проверки. На дисковом разделе размером в несколько гигабайт, что давно уже перестало быть редкостью, с большим количеством файлов и каталогов процедура проверки метаданных во время загрузки может очень сильно затянуться. А если выбило главный производственный сервер и теперь пользователи вынужденны ждать пока он перегрузится? Вот так мы плавно подошли к журналируемым файловым системам.
Что есть журнал?

            Вся магия журнала заключается в механизме транкзаций, этот термин довольно известен тем, кто работал с базами данных. Точно также как и в них, механизм транкзаций вместо отслеживания модификаций к таблицам и данным, рассматривает операцию записи на диск как атомарную, а не разделенную на несколько этапов, что позволяет отследить прошла ли запись вообще и в свою очередь гарантировать, что все или ни одно изменение файловой системы не сделано. Поясню сказанное на примере. Например, при создании нового файла изменяются несколько структур метаданных (inodes, списки свободных блоков, список файлов каталога и др.) Прежде, чем файловая система сделает изменения, создается транзакция, в которой описывается то, что собирается сделать. Как только транзакция будет зарегистрирована (на диске), файловая система приступает непосредственно к изменению метаданных. То есть фактически журнал в journaling файловой системе – просто список производимых операций. В случае системного сбоя, файловая система будет восстановлена к непротиворечивому состоянию, путем повторного запуска журнала и отката к предыдущему состоянию. К тому же в таком случае файловая система осматривает только те участки диска, в которых изменялись метаданные, т.е. она уже «знает» где произошел сбой. Это намного быстрее, чем при традиционной проверке с помощью fsck. И что самое существенное время восстановления совсем не зависит от размера раздела, а скорее зависит от интенсивности операций на момент сбоя. Можно выделить два возможных варианта работы журналируемой файловой системы. В первом варианте в журнал заносятся только изменяемые метаданные файла, в таком случае при сбое будет гарантированы метаструктуры файловой системы, а сохранность самих данных уже зависит от везучести. Во второй вариант предусматривает занесение в журнал вместе с метаданными, также и самих данных как изменившиеся, так и немодифицированные, в этом случае есть вероятность, что данные после сбоя будут восстановлены. И конечно же, как говорил мой преподаватель по теоретическим основам электроцепей «природу не обманешь, за все нужно платить», а платить теперь приходиться быстродействием так как самая медленная операция в компьютере это операции ввода/вывода на диск, количество таких операций возросло, особенно при использовании варианта с журналированием данных. Решают вопрос разными ухищрениями, например запись в момент наименьшей активности, дополнительно некоторые журналируемые файловые системы позволяют разместить журнал на другом физическом диске. Да и фактически время работы с журналом намного меньше, чем работа непосредственно с данными. И естественно некоторый полезный объем теперь приходится отводить под сам журнал, но он как правило не занимает места больше 32 Мб, что по нынешним временам не так уж и много.

В дополнение современные journaling файловые системы поддерживают:

-    более быстрое распределение свободных блоков, для этого большинство из них построено на основе сбалансированных деревьев, иначе известных как B+ деревья.

-    большее количество файлов в каталоге т.к. в этом случае обычная связка name-inode становится неэффективной, то опять же для хранения имен файлов используются B+ деревья. В некоторых случая возможно использование всего одного B+ деревья для полной системы, что намного укорачивает поиск файла и соответственно операции по работе с ним. Плюс динамическое выделение inides вместо неэффективного статического.

Старая методика прямого, косвенного т.д. механизма хранения информации о нахождении данных файла очень неудобная при работе с файлами большого размера, по причине долгого поиска информации заменена на более удобную, позволяющую работать с большими файлами «напрямую».

            Кроме того некоторые новые файловые системы имеют более совершенный механизм управления внутренней фрагментацией (что такое объясню чуть ниже) и распределения inodes чем Ext2. Может, сложиться впечатление, что место журналируемых файловых систем где-нибудь на сервере, нет они подходят на все сто процентов для использования на клиентских машинах, где тоже есть необходимость в сохранении данных. Теперь, когда мы точно знаем что ожидать от описываемых файловых системах, перейдем к их конкретной реализации.

            Хотя данная файловая система не была первой поддерживаемой ядром Linux официально (появилась только с версии 2.4.16) все таки справедливо будет начать именно с нее. Разработана она в недрах компании Red Hat доктором Stephen Tweedie. Что бы не изобретать колесо в данном случае поступили просто, прикрутив к стандартной ext2fs журнал. Фактически только добавив файл журнала (в зависимости от опций монтирования можно и не видеть, находится в ./.journal) и заменив драйвер ядра отвечающий за файловую систему, поэтому она естественно наследует все достоинства и недостатки присущие ext2fs . Но что это дало? Самое главное это то что утилиты ext2fs которые шлифовались в течении нескольких лет, работают в ней как ни в чем не бывало. К тому же идентичность файловых систем позволяет оперативно переходить как с еxt3fs на ext2fs, так и наоборот. Поясню. Мне часто приходится устанавливать другие дистрибутивы в том числе и со старыми ядрами не поддерживающими новинку. Так вот все разделы на которых используется ext3fs я монтирую просто как ext2fs и никаких, повторяю никаких недоразумений при использовании не происходит. Другое преимущество данной файловой системы состоит в том, что она в отличие от остальных поддерживает режим журналирования данных (полное или частичное). Естественно добавление журнала должно казалось должно ухудшить производительность данной системы по сравнению с «нежурнальным» вариантом. Оказалось, что за счет улучшения алгоритма движения головки жесткого диска данная файловая система в некоторых случаях даже обходит ext2fs. Ext3fs имеет три режима работы:

-            data=writeback – режим при котором не выполняется никакого журналирования данных, только метаданные, самый ограниченный режим журналирования (кстати, применяемый во всех других ФС рассматриваемых ниже) не гарантирующий сохранности данных после сбоя. Но за счет этого возрастает скорость работы такой файловой системы и фактически журнал предназначен только для того, чтобы уменьшить время начальной загрузки системы.

-            По-умолчанию же используется data=ordered - «золотая» середина между полным журналированием данных и предыдущим режимом. Официально в этом случае журналируются только метаданные, но блоки соответсвующих им данных записываются первыми. В большинстве случаев такой режим гарантирует сохранность данных, особенно если данные дописывались в конец файла, чего в большинстве случаев предостаточно. Производительность естественно чуть ниже предыдущей и выше полного журналирования которому отвечает режим

-            data=journal - в котором все новые данные сначала пишутся в журнал и только после этого переносятся на свое постоянное место. В случае аварийного отказа журнал можно повторно перечитать, приведя данные и метаданные в непротиворечивое состояние. Кстати, как оказалось данный режим в случае, когда диск интенсивно загружен операциями IO оказывается даже быстрее всех остальных.

#mount -o data=journal -t ext3 /dev/hda5 /usr/local

/dev/hda5 /usr/local ext3 data=writeback 1 0

/dev/hda5 /usr/local ext3 defaults 1 0

/dev/hda5 /usr/local ext2 defaults 1 0

# /sbin/tune2fs -j /dev/hdа5

# /sbin/mke2fs -j /dev/hdb5

            Вот и все о данной файловой системе. Что и говорить это предсказуемая и главное УДОБНАЯ файловая система. Характеристики по максимальному количеству файлов, каталогов и максимальных размеров разделов меня полностью устраивают. Но у нее есть недостаток доставшийся по наследству, который практически полностью решен в другой ФС.

ReiserFS

            Это первая «сторонняя» файловая система появившаяся в официальном ядре 2.4.4, но в первое время ее работа вызывала одни только нарекания и поэтому использовали ее только любители острых ощущений. Данный проект начинался в 90-ых годах, первый прототип носил название TreeFS. Разработана Хансом Райзером (Hans Reiser) и его компанией Namesys (http://www.namesys.com/) причем задачи они перед собой поставили революционные. Разработчики системы мечтают создать не только файловую систему, но вообще механизм иерархического именования объектов. Они считают, что лучшая файловая система та, которая формирует единую общедоступную среду – namespace. Для достижения этого, файловая система должна выполнять часть работы, традиционно выполнявшуюся приложениями, что уменьшит количество несовместимых API узкоспециального назначения. При таком подходе пользователи часто могут продолжать прямое использование файловой системы вместо формирования уровней специального назначения, типа баз данных и т.п. А вообще зайдите на сайт проекта там наилучшая документация из всех рассматриваемых проектов. Но предупреждаю ее там много. Базируется она на оптимизированных b* сбалансированных деревьях (одно на файловую систему) использование которых кроме увеличения поизводительности снимает ограничение на количество каталогов. Главное преимущество данной ФС проявляется в работе с маленькими файлами.
            Как я уже говорил информация на физическом носителе хранится не как попало, а отдельными блоками размер которых зависит и от размера раздела (это связано с максимально возможной адресацией) в том числе (устанавливается при форматировании), в большинстве случаев используется 4 кб. Так вот Еxt2 (и ext3 и FAT тоже) могут адресовать только целое количество блоков. Ну и что? Имеем файл 10 кб, размер блока 4 кб. Получается, что файл займет 2 целых блока и один только на половину. 4+4+2(и 2 осталось незанятыми, это и называется внутренней фрагментацией). Для единичного файла это не страшно, но если их несколько тысяч. По подсчетам в этих ФС теряется где-то от 6 до 10 процентов.
            Разработчики ReiserFS решили не решать кучи противоречивых задач, а остановились на одной и решили ее. А ReiserFS - может запросто упаковывать несколько маленьких файлов в один дисковый блок (tail packing), а совсем маленькие – вообще просто запихать в inode (внутрь b*tree). По необходимости для файла может ассигноваться точный размер. Такой режим работы предусмотрен по-умолчанию, но для повышения быстродействия есть возможность ее отключить. Хотя показатели ReiserFS при работе с большими файлами довольно высоки, именно работа с маленькими файлами (меньше кб) и обслуживание большого их количества выделяет данную ФС. По работе с ними она превосходит по быстродействию все представленные файловые системы. Именно за счет того, что данные и метаданные хранятся рядом, но с «разреженными» файлами работает все-таки хуже. Плюс как видите, достигается значительная экономия дискового пространства. Различные источники называют ReiserFS самой устойчивой из всех рассматриваемых ФС, ее я думаю можно рекомендовать для корневого раздела, который к тому же состоит из маленьких файлов. Такая себе рабочая лошадка. Но для работы с работы с данной ФС кроме поддержки ее самим ядром, необходимы также свои собственные утилиты для работы и обслуживания разделов они уже входят в стандартную поставку всех современных дистрибутивов.
                Если ядро уже поддерживает ReiserFS и имеется необходимые утилиты, то набрав
можно создать на ней соответствующую файловую систему. Для автоматического монтирования ее при загрузке достаточно прописать в файле /etc/fstab:

/dev/hda2 /home reiserfs notail 0 0

XFS

#/sbin/mkfs.xfs -d agcount=5 -l size=32m -f /dev/hdb2

JFS (Journaled File System)