Файловые системы Linux::Журнал СА 11.2003
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Подписка
Архив номеров
Где купить
Наука и технологии
Авторам
Рекламодателям
Контакты
   

  Опросы
  Статьи

Дата-центры  

Дата-центры: есть ли опасность утечки данных?

Российские компании уже несколько лет испытывают дефицит вычислительных мощностей. Рост числа проектов,

 Читать далее...

Книжная полка  

Защиты много не бывает

Среди книжных новинок издательства «БХВ» есть несколько изданий, посвященных методам социальной инженерии

 Читать далее...

Событие  

В банке рассола ждет сисадмина с полей фрактал-кукумбер

Читайте впечатления о слете ДСА 2024, рассказанные волонтером и участником слета

 Читать далее...

Организация бесперебойной работы  

Бесперебойная работа ИТ-инфраструктуры в режиме 24/7 Как обеспечить ее в нынешних условиях?

Год назад ИТ-компания «Крок» провела исследование «Ключевые тренды сервисного рынка 2023». Результаты

 Читать далее...

Книжная полка  

Читайте и познавайте мир технологий!

Издательство «БХВ» продолжает радовать выпуском интересных и полезных, к тому же прекрасно

 Читать далее...

СУБД PostgreSQL  

СУБД Postgres Pro

Сертификация по новым требованиям ФСТЭК и роль администратора без доступа к данным

 Читать далее...

Критическая инфраструктура  

КИИ для оператора связи. Готовы ли компании к повышению уровня кибербезопасности?

Похоже, что провайдеры и операторы связи начали забывать о требованиях законодательства

 Читать далее...

Архитектура ПО  

Архитектурные метрики. Качество архитектуры и способность системы к эволюционированию

Обычно соответствие программного продукта требованиям мы проверяем через скоуп вполне себе понятных

 Читать далее...

Как хорошо вы это знаете  

Что вам известно о разработках компании ARinteg?

Компания ARinteg (ООО «АРинтег») – системный интегратор на российском рынке ИБ –

 Читать далее...

Графические редакторы  

Рисование абстрактных гор в стиле Paper Cut

Векторный графический редактор Inkscape – яркий представитель той прослойки open source, с

 Читать далее...

День сисадмина  

Учите матчасть! Или как стать системным администратором

Лето – время не только отпусков, но и хорошая возможность определиться с профессией

 Читать далее...

День сисадмина  

Живой айтишник – это всегда движение. Остановка смерти подобна

Наши авторы рассказывают о своем опыте и дают советы начинающим системным администраторам.

 Читать далее...

Виртуализация  

Рынок решений для виртуализации

По данным «Обзора российского рынка инфраструктурного ПО и перспектив его развития», сделанного

 Читать далее...

Книжная полка  

Как стать креативным и востребованным

Издательский дом «Питер» предлагает новинки компьютерной литературы, а также книги по бизнесу

 Читать далее...

1001 и 1 книга  
19.03.2018г.
Просмотров: 6414
Комментарии: 0
Машинное обучение с использованием библиотеки Н2О

 Читать далее...

12.03.2018г.
Просмотров: 7118
Комментарии: 0
Особенности киберпреступлений в России: инструменты нападения и защита информации

 Читать далее...

12.03.2018г.
Просмотров: 4396
Комментарии: 0
Глубокое обучение с точки зрения практика

 Читать далее...

12.03.2018г.
Просмотров: 3086
Комментарии: 0
Изучаем pandas

 Читать далее...

12.03.2018г.
Просмотров: 3882
Комментарии: 0
Программирование на языке Rust (Цветное издание)

 Читать далее...

19.12.2017г.
Просмотров: 3897
Комментарии: 0
Глубокое обучение

 Читать далее...

19.12.2017г.
Просмотров: 6385
Комментарии: 0
Анализ социальных медиа на Python

 Читать далее...

19.12.2017г.
Просмотров: 3234
Комментарии: 0
Основы блокчейна

 Читать далее...

19.12.2017г.
Просмотров: 3530
Комментарии: 0
Java 9. Полный обзор нововведений

 Читать далее...

16.02.2017г.
Просмотров: 7364
Комментарии: 0
Опоздавших не бывает, или книга о стеке

 Читать далее...

17.05.2016г.
Просмотров: 10726
Комментарии: 0
Теория вычислений для программистов

 Читать далее...

30.03.2015г.
Просмотров: 12445
Комментарии: 0
От математики к обобщенному программированию

 Читать далее...

18.02.2014г.
Просмотров: 14097
Комментарии: 0
Рецензия на книгу «Читаем Тьюринга»

 Читать далее...

13.02.2014г.
Просмотров: 9192
Комментарии: 0
Читайте, размышляйте, действуйте

 Читать далее...

12.02.2014г.
Просмотров: 7142
Комментарии: 0
Рисуем наши мысли

 Читать далее...

10.02.2014г.
Просмотров: 5446
Комментарии: 3
Страна в цифрах

 Читать далее...

18.12.2013г.
Просмотров: 4683
Комментарии: 0
Большие данные меняют нашу жизнь

 Читать далее...

18.12.2013г.
Просмотров: 3495
Комментарии: 0
Компьютерные технологии – корень зла для точки роста

 Читать далее...

04.12.2013г.
Просмотров: 3212
Комментарии: 0
Паутина в облаках

 Читать далее...

03.12.2013г.
Просмотров: 3449
Комментарии: 0
Рецензия на книгу «MongoDB в действии»

 Читать далее...

02.12.2013г.
Просмотров: 3090
Комментарии: 0
Не думай о минутах свысока

 Читать далее...

Друзья сайта  

 Файловые системы Linux

Архив номеров / 2003 / Выпуск №11 (12) / Файловые системы Linux

Рубрика: Администрирование /  Архитектура

Сергей Яремчук СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС

Файловые системы 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-файловых систем поддерживаются:

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

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

Кроме того, некоторые новые файловые системы имеют более совершенный механизм управления внутренней фрагментацией (что это такое, объясню чуть позже) и распределения 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.

Например:

#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 Мб файловые системы показали такой результат, который, я думаю, в комментариях не нуждается.

Файловая система

Время операции, с

Загрузка процессора

Reiser4

171.28

30%CPU (1.0000x time; 1.0x CPU)

ReiserFS 3

302.53

16%CPU (1.7663x time; 0.53x CPU)

ext3

319.71

(1.8666x time; 0.36x CPU)

XFS

429.79

(2.5093x time; 0.43x CPU)

JFS

470.88

(2.7492x time 0.20x CPU)

Литература:

  1. Серия статей Advanced filesystem implementor’s guide Daniel Robbins: http://www-106.ibm.com/developerworks/linux/library/l-fs1, перевод которых можно найти на сайте http://www.softerra.ru.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-45
E-mail: sa@samag.ru