Автор работы: Пользователь скрыл имя, 13 Апреля 2013 в 17:10, доклад
Самое фундаментальное свойство любой файловой системы, влияющее на быстродействие всех дисковых операций — структура организации и хранения информации, т.е. то, как, собственно, устроена сама файловая система. Для начала хотелось бы заметить, что любая файловая система так или иначе хранит файлы. Доступ к данным файлов — основная и неотъемлемая часть работы с файловой системой, и поэтому, прежде всего, нужно сказать пару слов об этом. Любая файловая система хранит данные файлов в неких объемах — секторах, которые используются аппаратурой и драйвером как самая маленькая единица полезной информации диска. Одним из базовых понятий ФС является кластер - минимальный размер данных на диске.
Используя «последовательный» режим, записываются только изменения мета-данных файловой системы, что понижает избыточность между записью в файловую систему и в журнал, именно в связи с эти метод более быстрый. Не смотря на то, что изменения данных файла не записываются в журнал, они должны быть сделаны до изменений ассоциируемых мета-данных файловой системы, которые проводит журналирующий ext3 демон, что может немного снизить производительность вашей системы. Использование этого метода журналирования гарантирует что файлы в файловой системе никогда не будет рассинхронизированы со связанными мета-данными файловой системы.
Метод «обратная запись» наиболее быстрый, чем остальные два журналируемых метода, так как хранятся данные только о изменениях мета-данных файловой системы, и нет ожидания изменения ассоциируемых данных файла при записи (перед обновлением таких вещей как размер файла и информация о директории). Так как обновление данных файла производиться асинхронно по отношению к журналируемым изменениям мета-данных файловой системы, файлы в файловой системе могут показывать ошибки в мета-данных, например ошибка в указании владельца блоков данных (обновление которых к моменту перезагрузки системы было не закончено). Это не фатально, но может помешать пользователю
Политику переноса данных журнала на диск можно настраивать, но изначально она такова, что перенос происходит либо по заполнении 1/4 журнала, либо по истечении одного из таймеров переноса. Один из главных недостатков ext3fs происходит из того, что она изначально не задумывалась как именно журналируемая файловая система. Поскольку она основана на ext2fs, в ней отсутствуют многие прогрессивные нововведения, имеющиеся в других файловых системах (например, экстенты). Также она обычно показывает слабую производительность по сравнению с ReiserFs, JFS и XFS, однако меньше нагружает процессор и потребляет памяти, чем многие другие файловые системы.
Четвертая расширенная файловая система (ext4fs) - это дальнейшее развитие ext3fs. Ext4fs была задумана как замена ext3fs, имеющая с ней прямую и обратную совместимость, но включающая в себя множество улучшений (некоторые из которых нарушают эту совместимость). На практике можно монтировать раздел ext4 как ext3 и наоборот.
Во-первых, ext4fs - это 64-разрядная файловая система с поддержкой томов огромного размера (до 1 эксабайта). Она также может использовать экстенты, но в этом случае теряется совместимость с ext3fs. Аналогично XFS и Reiser4, в ext4fs размещение блоков на диске задерживается и происходит по необходимости (что уменьшает фрагментацию). Журнал также хранит контрольные суммы содержимого для большей надежности. Вместо B+- или B*-деревьев применяется специальная разновидность B-дерева, т.н. H-дерево, что позволяет поддиректориям иметь намного больший размер (в ext3 он ограничен 32Кб).
Хотя отложенное размещение уменьшает фрагментацию, со временем файловая система большого размера все равно фрагментируется. Для решения этой проблемы была разработана утилита e4defrag, которую можно использовать для дефрагментации отдельных файлов или целой файловой системы.
Еще одно интересное отличие ext4fs от ext3fs заключается в точности временной метки файлов. В ext3 размерность временной метки - одна секунда. Ext4fs смотрит в будущее: при непрекращающемся росте скоростей процессора и интерфейсов требуется более точное измерение. Поэтому в качестве размерности времени была взята одна наносекунда.
Хотя ext4fs включена в ядро Linux в версии 2.6.19, она уже может считаться стабильной. Эта система, разработка которой продолжается, является отправной точкой для создания журналируемой файловой системой будущего в Linux.
Лимит размера файла увеличился также: в то время, как в ext3 он был 2Т, в ext4 размер файла может быть до 16Т (максимальные размеры файла и файловой системы зависят от размера блока; указанные выше значения приведены для размера блока 4К).
JFS2 (также известная как улучшенная журналируемая файловая система) является первой журналируемой файловой системой и долгое время применялась в ОС IBM AIX®, прежде чем была перенесена в Linux. JFS2 - это 64-разрядная файловая система, которая, имея корни оригинальной JFS, была заметно усовершенствована в плане масштабируемости и поддержки многопроцессорных архитектур.
JFS2 поддерживает упорядоченное журналирование, обладает высокой производительностью и временем восстановления менее секунды. Для повышения быстродействия в ней применяется метод размещения файлов на основе экстентов. Размещение на основе экстентов означает размещение файла в виде нескольких непрерывных участков, а не множества одинаковых блоков. Благодаря непрерывности, эти участки обеспечивают более быстрое чтение и запись. Дополнительное преимущество экстентов - меньшие расходы на работу с метаданными. При размещении файла блоками записи подлежат метаданные каждого блока. Если используются экстенты, то изменяются метаданные для экстентов, которые обычно состоят из нескольких блоков.
JFS2 также использует B+-деревья как
для эффективного поиска по
каталогам, так и для
XFS - еще одна из ранних журналируемых файловых систем, первоначально разработанная Silicon Graphics в 1995 году для ОС IRIX. В 2001 году XFS была реализована в Linux, уже будучи на тот момент продуманной и надежной файловой системой.
XFS использует полноценную 64-
Другие интересные свойства XFS - это гарантированная скорость ввода/вывода, когда пользователям файловой системы выделяется резерв пропускной способности для операций ввода/вывода, и прямой ввод/вывод, при котором данные копируются напрямую между диском и буфером приложения (вместо того чтобы проходить несколько буферов). Журналирование в XFS ведется методом обратной записи.
Особенности
64-битная файловая система
Журналирование только метаданных
Изменение размера «на лету» (только увеличение)
Размещение в нескольких разных
линейных областях — т. н. «allocation groups»
(увеличивает
Дефрагментация «на лету»
API ввода/вывода реального
Запись на диск производится только при нехватке памяти. Это позволяет уменьшить фрагментацию, а также снизить активность запросов к диску.
Интерфейс (DMAPI) для поддержки иерархического управления хранением (HSM (англ.) )
Инструменты резервного копирования и восстановления (xfsdump and xfsrestore)
Реальный размер файла на файловой системе, в отличие от кратного размеру блока.
Очень большое количество «индексных блоков» inode.
Недостатки
Невозможно уменьшить размер существующей файловой системы.
Старые версии XFS страдали от опасности беспорядочной записи, которые могли привести к возникновению таких проблем как — файлы приложений во время краха/ошибки/аварии ФС или приложения набирали хвост из мусора к следующему монтированию ФС.
Версии загрузчика GRUB до 0.91 не поддерживают XFS.
Восстановление удалённых
Возможность потери данных во время записи при сбое питания, так как большое количество буферов хранится в памяти.
Относительно высокая нагрузка на центральный процессор
Вплоть до последних версий на 32-разрядных системах индексные блоки могут размещаться только в начальных 2-Терабайтах на диске. Поэтому, если вдруг при создании файла на XFS-диске с размером более 2 Терабайта выдается ошибка «невозможно создать файл» — попробуйте удалить какой-либо файл, который размещается на диске в начальных 2-Терабайтах, чтобы освободить место для новых индексных блоков.
ReiserFS . Очень часто бывает, что файл имеет размер, меньший размера логического блока. Вместо того чтобы выделять на каждый такой файл по целому блоку, оставляя часть блока незанятой (эту часть называют хвостом), в один блок стараются уместить несколько файлов. Такой способ дает выигрыш в 5% свободного места по сравнению с другими файловыми системами, но негативно сказывается на производительности.
Файловая система ReiserFS с самого начала создавалась как журналируемая. В 2001 году она была добавлена в главную ветку ядра 2.4 и стала первой журналируемой файловой системой, появившейся в Linux. Основной метод журналирования - упорядочивание. Поддерживается увеличение размера файловой системы "на лету". ReiserFS также поддерживает уплотнение хвостов для динамического уменьшения фрагментации, что позволяет ей обгонять по скорости ext3fs при работе с маленькими файлами.
В ReiserFS (также ее называют ReiserFS v3) применяется много современных подходов, например B+-деревья. Формат файловой системы базируется на единственном B+-дереве, что делает операции поиска особенно быстрыми и масштабируемыми. Политика переноса данных из журнала на диск зависит от размера журнала и основана на количестве блоков, требующих переноса.
Репутация ReiserFS была несколько раз подпорчена: последний раз - проблемами автора системы с законом (подробную информацию см. в разделе Ресурсы). Улучшенное журналирование в Reiser4 достигается за счет использования блуждающих записей и отложенного размещения блоков до момента переноса данных журнала (как это было сделано в XFS). В архитектуре Reiser4 предусматривалась гибкая поддержка плагинов (например, чтобы добавить функции сжатия или шифрования), но эта идея была отвергнута Linux-сообществом, которое считало, что место этим расширенным функциям - в подсистеме виртуальной файловой системы (VFS).
Раздел ReiserFS представляет собой набор блоков фиксированного размера. Блоки нумеруются последовательно, начиная с нулевого. Максимально доступное количество блоков на одном разделе – 2^32.
Раздел начинается с 64-х килобайт неиспользуемого пространства, оставленного под загрузчики, дисковые метки и прочие служебные надобности. Далее следует суперблок. Суперблок содержит важную информацию о разделе, например размер блока и местоположение корневого узла и journal node. Номер блока, содержащего суперблок, варьируется в зависимости от размера блока файловой системы, однако он всегда начинается с 65536-го байта раздела. Размер блока reiserfs в Linux по умолчанию равен 4 kb. Таким образом, суперблок содержится в 16-м блоке. Суперблок – один на весь раздел.
Сразу за суперблоком следует блок, содержащий битовую карту свободнго места. Количество блоков, отслеживаемых картой, напрямую зависит от размера блока. Большой раздел может иметь несколько bitmap-блоков.