UFS: эффект асинхронного монтирования

2004 г

Обескураживающие результаты тестирования файловой системы FreeBSD (UFS2, принятая в качестве нативной в 5-й ветке), выполненные ранее, не давали мне покоя. И даже то, что при использовании программного RAID (измерения проводились на дисках, объединенных ccd) скорость файловых операций уже не смотрелась столь мрачно, дела не меняло -- ведь сама по себе файловая системы тут не при чем.

И потому, установив новую ОС - DragonFlyBSD, - я решил вернуться к тестам на скорость файловых операций. В отличие от FreeBSD 5-й ветки, DFBSD сохранила верность первой версии файловой системы UFS. На этот раз в центре внимания был эффект асинхронного монтирования при отключении SoftUpdates - результаты предыдущих измерений показали, что при включении последнего механизма опция async просто игнорируется. Хотя, должен заметить, так было не всегда: в известной статье МакКазика и Ганджера (русский перевод) описаны результаты измерения быстроты файловых операций при включении SoftUpadates и монтировании в асинхронном режиме.

Измерения проводились на ноутбуке Toshiba Satellite Pro A40 с процессором Pentium-4/2,66 (Mobile), 512 Мбайт памяти, ATA-100 винчестером неизвестного происхождения (ни одна из утилит имени производителя мне так и не открыла) объемом 40 Гбайт, со скоростью вращения 4200 об./мин. В качестве "пробы пера", как и ранее, выполнялись следующие операции:

• копирование массива смешанных данных общим объемом 830 Мбайт;
• распаковка и копирование дерева портов FreeBSD (объемом около 25 Мбайт);
• копирование avi-файла размером 693 Мбайт.

Тесты для Ext2fs и ReiserFS проводились под управлением операционной системы Linux (дистрибутив Archlinux, ядро 2.6.8.1, установленное из умолчального бинарного пакета), для UFS - под DragonFlyBSD (октябрьский снапшот 2CSNAP-20041021-1130-GCC3, собранный с gcc3.4.1, ядро GENERIC).

Тесты осуществлялись на специально выделенном разделе объемом 5 Гбайт, на котором последовательно создавались файловые системы: Ext2fs, ReiserFS (для сравнения) и UFS. Для последней замеры проводились при включенном и отключенном механизме SoftUpadates. В последнем случае файловая система монтировалась в двух режимах: сначала умолчальном, частично асинхронному (опция noasync), а затем - чисто асинхронному (опция async). О смысле этих опций говорилось в одной из предыдущих заметок, а механизм SoftUpadates был описан в книге "Доступный Unix">. В каждых условиях все три теста выполнялись трижды (с размонтированием файловой системы в промежутке), за итоговый результат принималось среднее арифметическое. Что и можно видеть в таблице (результаты в секундах).

Тест	Работа с данными		Работа с портами			Большой файл
File Systems	Copy	Delete	Untar	Copy	Delete	Copy
Ext2fs	136	9	36	189	39	98
ReiserFS	150	3	46	96	30	95
UFS, noasync	393	49	271	356	258	115
UFS, async	252	14	74	129	69	116
UFS, SoftUp	274	15	235	339	188	115

Результаты измерений, которые можно видеть также на рисунке, несколько отличаются от полученных ранее. Что можно связывать с тем, что на низкоскоростном "железе" (напомню, речь идет о медленном ноутбучном винчестере) детали реализации конкретных файловых систем оказываются менее значимыми.

Рисунок. Результаты измерения быстродействия

Чтобы более не возвращаться к этому вопросу, начну с копирования большого файла. Тут мы видим распадение результатов на две группы: обе файловые системы Linux (лучшие, но практически равные, результаты) и все вариации на тему UFS (результаты столь же ровные, но на 15-20% худшие). Очевидно, это можно связать не столько с устройством файловых систем, сколько с быстродействием ATA-интерфейса в этих операционках.

В работе с массивом смешанных данных, как и ранее, чемпионом оказывается Ext2fs, за которой вплотную следует ReiserFS. В группе UFS-тестов характерен провальный результат этой файловой системы без задействования SoftUpdates, смонтированной в частично синхронном режиме. Чисто асинхронный режим демонстрирует некоторое превосходство над механизмом SoftUpdates - впрочем, не столь уж принципиальное.

Вполне предсказуемо, что во всем блеске асинхронный режим UFS проявляется на работе с портами - то есть огромным количеством очень маленьких файлов. Тут она не только более чем вдвое выигрывает у механизма SoftUpdates, но и (спешите видеть, впервые в мировой истории!) вполне значимо опережает Ext2fs на операции копирования. Хотя до ReiserFS и не дотягивает - ведь это коронный номер последней.

В общем, можно констатировать, что отказ от SoftUpdates в сочетании с асинхронным монтированием несколько повышает быстродействие файловых операций на UFS. Конечно, это влечет за собой и снижение надежности файловой системы. А поскольку никаких механизмов журналирования для UFS нет и не предвидится, последний фактор является определяющим для серверных применений. На пользовательском же десктопе, снабженном бесперебойником (а последний, ИМХО, должен являться непременным атрибутом нормальной Unix-машины), это не столь критично. Конечно, монтировать в асинхронном режиме корневую файловую систему не стоит. Да и не имеет смысла - по нормальному она изменяется только при реинсталляции ядра. Однако для таких ветвей файловой системы, как /usr/src, /usr/obj, /usr/ports, /usr/ports/distfiles, асинхронное монтирование видится вполне подходящим. Конечно, наибольший эффект оно дало бы для каталога /home. Однако тут каждый должен решать для себя сам - рисковать ли хоть ничтожным шансом на разрушение файловой системы ради быстродействия, или нет.

UFS2 на ccd: продолжение банкета с быстродействием

2004 г

Должен сказать, что результаты, изложенные в прошлой заметке на тему быстродействия файловых систем, меня несколько обескуражили. И главное, возник вопрос: если, как в старом советском анекдоте, с быстродействием UFS2 все так плохо, то почему же на самом деле с ним все так хорошо?

Иными словами, визуально при работе я, конечно, видел, что UFS2 медленнее всех когда-либо реально применявшиеся файловых систем для Linux. Но уж далеко не настолько, как получалось по результатам измерений.

И тут я сообразил, что реально-то я работаю не совсем в той конфигурации, которая была описана в той заметке. Потому что на самом деле в моей машине живет еще два диска - Seagate Barracuda IV, по 80 Гбайт каждый, объединенные в программный RAID нулевого уровня (strip) посредством ccd; просто на время тестирования они были отключены физически. И я решил посмотреть - а дает ли это что-нибудь в плане быстродействия.

Итак, методика измерений осталась прежней, объекты для манипулирования - также. А из железа добавились два вышеперечисленных винчестера, один - слейвом на первом IDE-канале (в паре с 40-гигабайтником, несущим систему), другой - мастером на втором. На них размещались: вначале по гигабайтному swap-разделу, далее - по разделу 4.2BSD, размером 20 и 60 Гбайт на каждом.

Двадцатигигабайтные разделы были объединены в ccd-устройство со стриппингом, под UFS2, монтировавшееся в качестве /usr/ports/distfiles - о нем далее речи не будет. А 60-гигабайтные разделы составили еще один программный ccd-RAID, также с расслоением (размер блока - 128 Кбайт, примерная методика описана в одной из моих заметок по FreeBSD). Объединенный раздел с UFS2 монтировался у меня в обычном состоянии как /home и нес на себе все данные, с которыми я постоянно работаю (средняя заполненость - около 70%).

Перед началом измерений файловая система /home была размонтирована и смонтирована как /mnt/hd. Как и в прошлый раз, последовательно выполнялись копирование массива данных и его удаление, развертывание, копирование и удаление дерева портов, копирование и удаление большого avi-файла. После каждого цикла файловая система размонтировалась, перемонтировалась заново и измерения повторялись - всего троекратно, в качестве результатов принимались средние значения.

Создавать на ccd специальный раздел специально для тестирования у меня возможности не было, поэтому все действия (копирование массива данных, развертывание и копирование дерева портов, копирование большого файла) выполнялись прямо в рабочем разделе. Что, конечно, оказывало некоторое (из общих соображение - негативное) влияние на результаты. Тем не менее, как можно видеть из таблиц 1 и 2, они оказались весьма показательными. Для большей наглядности я разделил данные для копирования/"растаривания" и для удаления. В качестве предмета сравнения выступили результаты для UFS2 и Ext2fs из прошлой заметки - обе в "умолчальных" режимах на 5-гигабайтном разделе одиночного диска.

Таблица 1. Копирование и "растаривание"

FS+Mode	Data	Untar	Ports	Big
UFS,default	211	189	255	104
UFS,ccd	185	107	175	83
Ext2,default	71	90	68	45

Сначала о копировании и "растаривании". Уже копирование массива данных дало более чем 10-процентный выигрыш в скорости против UFS2 на одиночном диске. При "растаривании" превосходство составило уже почти 50%, при копировании дерева портов - более 30%, и при копировании большого файла - более 20% (рис. 1).

Рис. 1. Копирование и "растаривание"

Результаты - не потрясающие воображения, но вполне весомые, а для "растаривания" уже сравнимые с ext2fs. Однако при удалении файлов все оказалось еще интересней (см. табл. 2).

Таблица 2. Удаление

FS+Mode	Data	Ports
UFS,default	7	92
UFS,ccd	5	34
UFS,ccd	5	34

Удаление массива данных с ccd-раздела происходило быстрее, чем с единичного UFS2, и даже чем с раздела ext2fs - хотя, при столь низких абсолютных значениях их трудно считать статистически значимыми. А вот на удалении дерева портов выигрыш во времени составил более 60% (рис. 2). Удаление же единичного файла происходило практически мгновенно и потому время его здесь не приводится.

Рис. 2. Удаление

Таким образом, на типично пользовательских задачах использование программного RAID со стриппингом (по крайней мере, в исполнении ccd, для vinum данных у меня, по понятным причинам, нет) дает вполне реальный (а иногда и просто значительный) прирост в быстродействии файловых операций. А поскольку нынче редкая мама не оснащается дополнительным IDE-контроллером, появляется возможность разнести винчестеры на отдельные линии (даже без задействования аппаратного ATA RAID), что должно еще более улучшить результаты.

Возникает еще один интересный вопрос: а как влияет (и влияет ли вообще) на соотношение быстродействия файловых систем рост физического быстродействия винчестера. Поскольку давеча я обзавелся SATA-диском, теоретически более быстрым, чем мои относительно старые PATA, рассчитываю в ближайшее время исследовать и этот вопрос.

FreeBSD vs Linux: быстродействие файловых систем

2004 г

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

Цели и задачи

Сначала я ставил себе очень ограниченную задачу - измерить быстродействие современной файловой системы FreeBSD - UFS2 - в разных режимах монтирования. Как известно, по умолчанию она монтируется в т.н. режиме noasync, при котором изменения метаданных файлов записываются на диск синхронно, а для собственно данных применяется асинхронная запись, то есть кэширование. Что изначально ставит UFS2 в невыгодное (с точки зрения быстродействия) положение по сравнению с Linux, где по умолчанию для большинства файловых систем, поддерживаемых этой операционкой в качестве нативных, принят чисто асинхронный режим - с кэшированием не только данных, но и метаданных.

Однако теоретически чисто асинхронный режим существует и во FreeBSD, хотя использование его крайне не рекомендуется во всех официальных документах проекта, как способствующее падению надежности. Что, безусловно, верно для серверов, но не кажется столь уж критичным для десктопов, оснащенных бесперебойниками (а бесперебойник, по моему скромному мнению, - непременный атрибут любой Unix-машины, особенно в условиях постсоветской действительности). Так что возникло естественное желание - поглядеть, а как ведет себя UFS2 в асинхронном режиме.

Сразу замечу, что первые же результаты измерений оказались несколько неожиданными и, по крайней мере для меня - не вполне понятными. И потому для прояснения ситуации я решил сравнить их с проведенными в аналогичных условиях измерениями для ext2fs в Linux. Ну а дальше - больше, стало интересным сопоставление с прочими файловыми системами Linux. И, наконец, возник вопрос, а как эти операционки работают с файловыми системами друг друга. Поскольку поддержка в Linux UFS2 ныне не реализована (да и включить поддержку UFS просто - задача не тривиальная), пришлось ограничиться измерениями только для ext2fs под FreeBSD. Таким образом и определились

Участники тестирования

Итак, первым участником, естественно, стала UFS2, образованная с параметрами по умолчанию sysinstall (размер блока - 16384 байт, размер фрагмента - 2048), с предусмотренным этой утилитой включением режима SoftUpdates. И монтируемая в умолчальном же, то есть частично асинхронном (опция -o noasync, принимаемая по умолчанию при исполнении команды mount) режиме.

Далее, исходя из общих соображений, можно было предполагать, что на быстродействие файловых операций может влиять также опция -o noatime, запрещающая обновление времени последнего доступа для файлов. Затем, разумеется, был опробован чисто асинхронный режим (опция -o async). И, наконец, сочетание обеих опций, от которого теоретически следовало ждать максимального быстродействия.

В качестве объектов сравнения выступили нативные файловые системы Linux. В первую голову это, конечно, была классическая ext2fs, монтировавшаяся в двух режимах - умолчальном и в режиме -o noatime.

Затем - ее журналируемый вариант, ext3fs. Для нее штатно предусмотрено три режима использования - полного журналирования (опция -o data=journal), при котором фиксируются операции не только с метаданными файлов, но и их данными, стандартного частичного журналирования (опция -o data=ordered, при которой данные и метаданные группируются в единый блок транзакции) и режима writeback, в котором никакого журналирования данных не осуществляется. От использования опции -o noatime я в данном случае отказался (честно говоря, просто из лени - хотя, как стало ясным из результатов, ничего принципиально нового эта опция не дала бы).

Далее - ReiserFS, самая претенциозная (и, пожалуй, наиболее популярная среди пользователей Linux) журналируемая файловая система. Здесь, кроме умолчального, я снова опробовал режим с отказом от обновления atime - и, как показала практика, не напрасно).

Аналогично я поступил и с XFS - измерения на ней производились в умолчальном режиме и в режиме с опцией -o noatime. И, наконец, в отношении JFS я ограничился режимом по умолчанию - так как этой системой никогда практически не пользовался, мало чего о ней знаю и привлек ее к делу исключительно для сравнения.

Все файловые системы создавались посредством соответствующих утилит (mke2fs - для ext2fs и ext3fs, mkreiserfs и mk.xfs - для одноименных файловых систем, jfs_mkfs - для JFS) с параметрами по умолчанию. Исключением стала XFS, для которой размер allocation group и объем журнала были подобраны в соответствие с рекомендациями Дэниэла Роббинса (объем журнала - 32 Мбайт, минимум одна allocation group на 4 Гбайт дискового пространства, отводимого под эту файловую систему).

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

О тестовой платформе

Измерения производились на подручном железе, каковое содержало:

• процессор Pentium-4/2,53 Ггц, FSB 533, без HT;
• материнская плата Albatron PX845PE на одноименном чипсете, в варианте с дополнительным контроллером ATA RAID/SerialATA Promise FastTrack 376 (впрочем, не задействованным);
• 1 Гбайт оперативной памяти (2x512 PC-2700, продававшейся под брэндом "якобы Samsung");
• жесткий диск Seagate Barracuda IV 40 Гбайт, интерфейс ParallelATA, 7200 об./мин., подключенный как single на 1-й канал стандартного ATA-контроллера из южного моста ICH4.

Прочие компоненты, типа CD-ROM (single на втором IDE-канале), значения в данном случае не имеют.

На диске имелось 4 первичный раздела. Первый, объемом 30 Мбайт с файловой системой ext2fs, исполнял функции загрузочного и нес на себе только GRUB (и ядро Linux). Второй раздел был определен как BSD-слайс, и в нем, на файловой системе UFS2, размещалась FreeBSD 5.2.1. Третий раздел был объявлен DOS Extended и нес на себе Archlinux 0.6 (ядро 2.6.6). Детали их разбиения, а также файловые системы, в данном контексте не существенны.

Во о избежание недоразумений замечу, что в обеих ОС диск функционировал в штатном режиме UDMA100, что определялось утилитами atacontrol во FreeBSD и hdparm в Linux.

И еще: FreeBSD была подвергнута процедуре make world с флагами оптимизации -O1 и -march=pentium4. Ядро, пересобранное на базе очень облегченного GENERIC (с исключением поддержки всего отсутствующего, типа SCSI и сетевых карт), компилировалось с флагом -O2 под тот же Pentium-4. Для Archlinux использовалось штатное прекомпилированное (из репозитория проекта - current) ядро, собранное, как и вся система в целом, с флагами -O2 -march=i686.

Впрочем, все сказанное в предыдущем абзаце вряд ли способно было кардинально повлиять на производительность при файловых операциях. И потому для нас важен только четвертый первичный раздел, объемом 5,5 Гбайт, который и подвергался всяческим издевательствам. Для чего на нем, после присвоения соответствующего идентификатора (4.2BSD или Linux native, соответственно), на нем создавались перечисленные в предыдущем разделе файловые системы, которые монтировались с указанными опциями. А на них уже помещались те данные, которые представляли собой

Объекты тестирования

Измерения я затевал для личных целей, и потому меня больше всего интересовали операции с теми данными, с которым я имею дело регулярно. А это а) массивы смешанных данных (тексты и иллюстрирующая их графика), б) массивы из огромного количества очень маленьких файлов (типа дерева портов FreeBSD и аналогичных систем управления пакетами из Source Based дистрибутивов Linux) и в) большие файлы, от объема CD и выше. В соответствие с этим я и подобрал тестовые объекты.

Во-первых, это был каталог моих рабочих материалов - файлов в форматах plain text и html с иллюстрациями в форматах gif, tiff, jpeg, png, объем которых варьировал от нескольких килобайт до первых десятков мегабайт. Для оживления картины я разбавил его звуковыми файлами mpeg (от 1,5 до 6 Мбайт каждый). В результате первый тестовый массив суммарно составил 830 Мбайт.

Вторым объектом было подручное дерево портов FreeBSD от 6 мая 2004 г., объемом 24,2 Мбайт, и результат его "растаривания", что давало каталог в 124 Мбайт. Специфика его - в том, что он образован огромным (свыше 100 тысяч) количество файлов, преобладающий размер которых - несколько сот байт.

Наконец, третьим объектом стал avi-файл размером в CD - 693 Мбайт.

Ничего лучшего, чем измерять время копирования этих массивов, я не придумал. То есть каталог данных копировался командой вида

$ cp data newdata

с последующим уничтожением целевого каталога

$ rm -Rf newdata

и замеров времени каждой операции посредством вывода команды date до и после нее. Аналогично я поступал и с большим файлом. А тарбалл портов предварительно разворачивался командой

$ tar xzvf ports.tar.gz

время чего также замерялось - это ведь не только скорость декомпрессии и разархивации, зависящая от быстродействия процессора, но и скорость инкорпорации результата в файловую систему. В целях облегчения жизни операции над каждым объектом выполнялись из простенького скрипта вида

date >> file_of_result &&
command1 &&
date >> file_of_result &&
...
date >> file_of_result &&

Все три теста для каждой файловой системы в каждом режиме выполнялись трижды. По завершении цикла файловая система размонтировалась и перед повторением монтировалась заново. В качестве результирующих принималось среднее арифметическое из трех значений.

Результаты

Результаты измерений скорости выполнения всех операций над тремя объектами приведены в таблице и на рис. 1-3. Единицы измерения - секунды, соответственно, меньшие значения везде отвечают лучшим показателям. Которые мы и рассмотрим последовательно для всех файловых систем.

UFS

Начнем с той, что послужила первопричиной этой заметки - с UFS2. Напомню, что она монтировалась последовательно в четырех режимах - умолчальном, с включением опции -o noatime, в чисто асинхронном режиме (опция -o async) и, наконец, с включением обеих этих опций. Теоретически рассуждая, в этом порядке и должно возрастать быстродействие файловых операций. Что же мы видим на практике?

Таблица. Результаты измерения (в сек.) быстродействия файловых операций в различных файловых системах

Тест	Работа с данными		Работа с портами			Большой файл
FS+Mode	Copy	Delete	Untar	Copy	Delete	Copy	Delete
UFS,default	211	7	189	255	92	104	0
UFS,noatime	210	7	194	333	99	102	0
UFS,async	211	8	201	352	99	103	0
UFS,both	209	6	202	344	98	103	0
Ext2,FreeBSD	222	25	280	309	222	150	1
Ext2,default	71	6	90	68	7	45	0
Ext2,noatime	73	6	93	68	7	46	0
Ext3,journal	123	6	134	58	6	98	1
Ext3,ordered	81	15	107	115	17	50	16
Ext3,writeback	91	7	107	68	51	53	1
Reiser,default	100	2	59	51	7	44	1
Reiser,noatime	89	2	71	26	7	47	1
XFS,default	95	9	76	83	41	48	0
XFS,noatime	97	9	80	74	42	49	0
JFS,default	132	13	267	160	19	91	0

Результаты по копированию массива данных (см. рис. 1) во всех четырех режимах можно считать практически идентичными. Казалось бы, чуть лучшие результаты позволяет получить отказ от обновления atime, однако и абсолютно, и относительно разница ничтожна. И в любом случае, включение асинхронного режима не обеспечивает никакого скачка в быстродействии, которого можно было бы ожидать, исходя из общих соображений. Скорость удаления смешанного массива файлов также примерно одинакова: несколько лучшие результаты при включении обеих опций лежат, скорее всего, в пределах ошибки эксперимента (точность вывода команды date - в пределах одной секунды).

Рис. 1. Работа с массивом смешанных данных

Еще более впечатляющий график демонстрируют результаты работы с деревом портов (рис. 2). Теоретически можно было бы ожидать резкого скачка быстродействия при асинхронной обработке огромного количества мелких файлов. Однако на практике мы видим прямо противоположную картину: наилучшие результаты и при разворачивании тарбалла, и при копировании дерева портов, и при его удалении получаются как раз при умолчальном, синхронном для метаданных, режиме. Причем в случае копирования превосходство его выглядит вполне значимым: включение любой из дополнительных опций (а особенно - их обеих) вызывает падение скорости этой операции на 30-50%.

Рис. 2. Работа с деревом портов

Копирование большого файла - единственная операция, где умолчальный режим показывает как будто бы самые худшие результаты (рис. 3). Однако разница и в абсолютных величинах, и в относительных выглядит просто смехотворной. И, скорее всего, опять же имеет причиной естественный разброс в пределах ошибки. Ну а удаление единичного файла, как и следовало ожидать, происходит практически мгновенно (хотя, как мы увидим далее, и это - не само собой разумеющееся наблюдение).

Рис. 3. Работа с большим файлом

Лично я вижу одно объяснение наблюдаемой картине: асинхронный режим при монтировании современной файловой системы FreeBSD - не более чем фикция, и на самом деле метаданные в любом случае обрабатываются синхронны. Ну и в любом случае можно только порадоваться за разработчиков этой ОС: предлагаемый ими умолчальный режим монтирования обеспечивает или лучшие, или практически не худшие результаты, чем любые иные, требующие дополнительных опций и, соответственно, лишних телодвижений.

Минус этого - то, что резервов повышения быстродействия файловых операций во FreeBSD обнаружить не удается. Посмотрим же теперь, что мы теряем, отказываясь в ее пользу от Linux с его многочисленными файловыми системами.

Ext2fs

Начнем опять же с классики жанра - традиционной ext2fs. При копировании массива смешанных данных она показывает завидное быстродействие, более чем втрое превосходящее скорость этой операции в UFS2, при сопоставимой (но формально лучшей) скорости удаления. Если же отвлечься от абсолютных цифр, можно видеть, что включение опции noatime и здесь, вопреки ожиданию, ничего не дает в плане производительности.

Та же картина наблюдается в тесте с деревом портов. И развертывание тарбалла, и копирование каталога мелких файлов, и его удаление происходят одинаково быстро вне зависимости от того, обновляется ли время последнего доступа или нет. Относительно UFS2 это самое "быстро" выражается двух- (для операции "растаривания") и даже пяти- (для копирования) кратным превосходством. Ну а удаление дерева портов вообще более чем на порядок быстрее - фактически такое же быстрое, как и удаление смешанного массива.

При работе с большим файлом также никаких неожиданностей не наблюдается: копируется он быстро (более чем вдвое быстрее, чем в UFS2), а удаляется практически мгновенно.

В общем, приходится с прискорбием констатировать, что в плане быстродействия UFS2 и близко не лежала с ext2fs, чем бы это ни объяснялось (desktop-пользователю эти объяснения по большому счету до лампочки). И потому интересно посмотреть, а не проявит ли себя ext2fs со столь же хорошей стороны также и во FreeBSD?

Опять же, как это ни печально, не проявит. Смонтированная по умолчанию, она под этой ОС демонстрирует просто провальное быстродействие. Точнее, полное его отсутствие - результаты по всем тестам хуже (а в отношении портов и большого файла - много хуже), чем для родимой UFS2. Причем показательно, что даже своей хорошей скорости удаления файлов она тут не сохраняет, умудрившись чуть-чуть выделиться даже при стирании единичного большого файла.

Конечно, ext2fs по самой своей природе не может быть такой же надежной, как UFS2. И ее потенциальную склонность к разрушению (а были времена, когда ext2fs почти гарантированно рушилась при аварийном завершении работы системы) пытается скомпенсировать настраивающая ее журналируемость, прикручивание которой дает самостоятельную файловую систему - ext3fs. Посмотрим, дорого ли приходится платить за это в плане скорости.

Ext3fs

Как уже говорилось, в ext3fs предусмотрено три режима монтирования - с полным журналированием метаданных и данных, с полным журналированием метаданных и частичным данных (на самом деле это не совсем строго, но за деталями режима ordered предлагаю обратиться к специальным источникам), и без всякого журналирования данных вообще. В официальной документации по ext3fs утверждается, что надежность системы падает в порядке перечисления, а быстродействие, напротив, возрастает. Соответственно, по умолчанию ext2fs монтируется в том режиме, который разработчики считают промежуточным в обоих отношениях, то есть в режиме ordered.

Вопросы надежности мы здесь не обсуждаем, а вот что касается быстродействия... При копировании массива смешанных данных режим journal действительно оказывается наиболее медленным, однако первенство остается за режимом ordered (а не writeback, как следовало бы ожидать). А вот стирание результатов этого копирования вообще показывает парадоксальную картину: если при режимах journal и writeback скорость удаления каталога ожидаемо быстра (практически такая же, как в ext2fs), то в режиме ordered эта процедура выполняется просто неприлично медленно (15 секунд против 6-7, как можно видеть из таблицы).

Рассмотрение работы с мелкими файлами оставляет очень противоречивое ощущение. Развертывание архива - наиболее медленно в режиме полного журналирования, и несколько быстрее (и одинаково) - в обоих режимах журналирования частичного. С копированием дерева портов неожиданно лучше всего справляется режим journal, режим writeback оказывается несколько медленнее, а ordered эту задачу просто проваливает - скорость операции удаления оказывается в нем вдвое ниже остальных.

Дальше - больше: график скоростей удаления дерева портов просто обратен теоретически ожидаемому: блестящий результат в режиме полного журналирования (6 секунд - чуть не лучше, чем для ext2fs), посредственный (17 секунд) - в режиме ordered, и наихудший для всех файловых систем Linux (51 секунда) - в якобы быстрейшем режиме writeback.

Наконец, обращение с большим файлом дает нам очередную (уже ожидаемую) неожиданность: распределение скоростей копирования повторяет таковое для дерева портов (лучший результат - в режиме ordered, похуже, но близкий - в режиме writeback, и существенно худший - в режиме journal, 50, 53 и 98 секунд, соответственно). Но зато при удалении этого самого большого файла режим ordered отличился как никто: в нем эта процедура заняла аж 16 секунд. Не просто хуже всех, а недосягаемо хуже. И еще раз подчеркну, что речь идет не о случайном всплеске, а о среднем из трех измерений, разделенных перемонтированием файловой системы.

Как будет видно из дальнейшего, ext3fs с точки зрения быстродействия вообще смотрится бледновато на фоне прочих файловых систем, с которыми работает Linux. Но против FreeBSD она все равно сохраняет преимущество по всем позициям: усилиями всех трех режимов журналирования изначальную ext2fs не удается низвести до уровня частично синхронной UFS2. И даже худший результат ext3fs при работе с портами остается недосягаемых для той ОС, в которой сама идея портов появилась впервые.

Однако, говоря о портах, я несколько забежал вперед. Потому что сначала следовало бы посмотреть, а какая файловая система держит первенство в работе с большим количеством маленьких файлов?

ReiserFS

Эта файловая система изначально проектировалась (в том числе и) для эффективного обращения с большим количеством маленьких файлов - в частности, экономии занимаемого ими пространства для. Однако сейчас нас интересует быстродействие - и для всех файлов вообще. Так что начнем с массива смешанных данных.

И тут мы впервые видим торжество теоретических предсказаний: умеренное быстродействие при копировании нашего массива в режиме по умолчанию увеличивается на 10% при включении режима noatime - со 100 секунд до 89 (хотя и не достигает рекордного). Но зато рекорд бьет удаление копируемого массива - по 2 секунды в каждом из режимов.

Дерево портов... Превосходные результаты при "растаривании" и копировании в умолчальном режиме. При отмене обновления atime в первом случае они несколько ухудшаются. Но зато - браво - копирование с этой опцией осуществляется практически вдвое быстрее, чем без нее; такого результата мы еще не видели. И опять ReiserFS близок к рекорду при удалении портового безобразия - финишируя голова в голову с ext2fs.

И последняя неожиданность от детища Ханса Райзера - в копировании большого файла оно показывает себя в числе лучших, хотя тут влияние noatime и не сказывается. Посмотрим, сможет ли потягаться с этим XFS, которая, напротив, по замыслу предполагалась именно для хранения мультимедийной информации.

XFS

На массиве данных общего характера копирование дает результат, близкий к гармоническому среднему, время же удаления их кажется чуть-чуть завышенным (9 секунд).

Работа с портами - на среднем уровне в отношении "растаривания" и копирования. И - неожиданно большое время удаления дерева портов (более 40 секунд), приближающееся к "анти-рекорду" writeback-режима ext3fs (хотя все равно много лучшее, чем для UFS2).

А вот результат по большому файлу (48-49 секунд) - не порадовал: хотя он и в числе лучших, но от "мультимедийной" файловой системы я ожидал большего. Хотя, может быть, с точки зрения SGI, это 700 Мбайт - это отнюдь не много? И в утешение - провала при удалении большого файла также не отмечается:-).

JFS

Эпоним журналируемых файловых систем выступает в нашем зачете вне конкурса - причинам, о которых говорил выше. И результаты показали, что это было вполне оправданно. Ибо мы имеем:

• худший среди всех файловых систем Linux результат в копировании смешанного массива и второй с конца (после провала ordered-режима etx2fs) - в его удалении;
• худший результат "растаривания" среди всех нативных файловых систем вообще, включая UFS2; хуже оказалась только ext2fs из под FreeBSD - но ведь с чужака и взятки гладки;
• прямо скажем, не блестящее время удаления дерева портов;
• копирование большого файла - финиш в плотной группе отстающих.

В общем, JFS, единственной из поддерживаемых Linux файловых систем, оказалась сопоставимой с UFS2 по быстродействию (вернее, отсутствию оного). Конечно, нельзя исключить, что знатоки ее могут повысить производительность какими-либо опциями; в частности, я где-то слышал, что Linux-версия JFS стандартно работает чуть не в чисто синхронном режиме - глядя на результаты, в это вполне можно поверить. Однако, повторяю, по умолчанию она предстает перед пользователем в качестве самой медленной.

Выводы

Должен сказать, что проведенные измерения существенно перевернули мои представления о файловых системах вообще (хотя кое в чем и укрепили).

В частности, я всегда подозревал, что обе файловые системы FreeBSD - и старая UFS, и новая UFS2, - уступаю своим Linux'овым сестрам в быстродействии. Да это обычно видно и, что называется, органолептически. Однако я никак не ожидал, что для UFS2 в количественном отношении отставание окажется столь существенным. Должен заметить - выполнявшиеся мной ранее измерения для UFS просто столь разительной тормознутости не показывали - даже в отношении ext2fs (для ReiserFS меньший разрыв можно было бы объяснить младенческим тогда ее возрастом). Не исключено, что это - расплата и за 64-битную адресацию, и за вдвое увеличенные inodes...

Далее, я не ожидал столь достойных результатов ReiserFS не только в отношении очень маленьких файлов, но и во всех остальных тестах. Так что беру назад все не очень хорошие слова, которые ранее говорил в ее адрес. Правда, непроверенным осталось эмпирически наблюдаемое (но не подтверждавшееся количественно) явление падения ее производительности на больших (более 100 Гбайт) разделах, размещенных на программном RAID - но для многих ли desktop-пользователей это актуально?

Не показала себя в ожидавшемся блеске и столь любимая мною раньше XFS. Все же мало когда приходится работать с файлами более объема сидюшника, а в этих пределах она оказалась не быстрее ReiserFS.

А вот в чем измерения меня укрепили - так это в предубежденном (и неблагоприятном) отношении к ext3fs. И дело даже не в том, что хоть каком-нибудь ее режим "отличился" хотя бы на одном тесте. Недовольство вызывает именно непредсказуемость ее поведения в зависимости от режима и характера данных. Вероятно, разработчики имели основания для заключения об оптимальности режима ordered - однако основывались они, судя по всему, на задачах серверных, но отнюдь не десктопных.

Так какую же файловую систему выбрать простому настольному пользователю для своей отдельно взятой персоналки? Мой ответ не будет блистать оригинальностью, если я заявлю со всей определенностью: каждому овощу - свой фрукт. И бесполезно пытаться найти систему, одинаков быструю и для хранения дерева портов (или их Linux-аналогов), и для сборки iso-образов под резервное копирование, и прочая, и прочая, и прочая.

К счастью, пользователь FreeBSD избавлен от этих терзаний - UFS и UFS2 суть объективные реальности, данные ему в ощущениях берклианских разработчиков. Только он должен понимать, что по крайней мере при работе с файлами ему придется поступиться быстродействием ради стройности и аккуратности используемой системы. Впрочем, не компенсируется ли потеря времени на копировании файлов отсутствием мытарств с несовпадением версий библиотек или компиляторов?

А вот пользователю Linux есть над чем поломать голову. Потому что однозначно я не рекомендовал бы к употреблению только JFS - да и то, не факт, что, прочитав многопудовую документацию к ней, я был бы столь категоричен (другое дело, что пока ни одна из особенностей этой файловой системы не способна подвигнуть меня на такое чтение, тем более по англицки).

Ибо даже нелюбимой мною ext3fs можно найти применение. В частности, для корневой файловой системы в том случае, когда из нее в отдельные ветви вынесены /var, /usr, /opt (если в данном дистрибутиве задействуется активно), и, конечно же, /home.

Для первых трех ветвей подходящей видится ReiserFS. Особенно если у нас - Source Based дистрибутив, использующий какую-либо портообразную систему. И к слову - идеальной она окажется именно тогда, когда дерево этих портоидов вынесено в отдельную ветвь внутри /usr или /var. А еще измерения склонили меня к мысли, что и для /home ReiserFS более чем пригодна - раньше я ничего, кроме XFS, в этом качестве не признавал. Хотя и теперь не вижу причин, почему бы благородному дону не размещать на XFS свои данные - особенно если он не имеет привычки часто и в большом количестве их удалять.

Наконец, ext2fs - отнюдь не худший выбор для многих пользователей, не желающих заморачиваться созданием множества разделов и подбором под них идеальных файловых систем (при условии наличия бесперебойника, разумеется). И уж совсем незаменимой она оказывается а) для обмена данными с установленной на той же машине FreeBSD, и б) для раздела /boot в случае использования мультизагрузчика GRUB. Так что и старушку ext2fs рано еще списывать в тираж...

Linux и файловые системы: еще раз о проблеме выбора

Citkit, 15 марта 2007 г

Весна наступила... Индо взопрели озимые, солнышко рассупонилось. Старик Ромуальдыч начал к своей портянке принюхиваться - оттаяла, видать. Податтаяли и пользователи - на форумы потянулись, вопросы задавать, да ответы получать...

Одним из популярных вопросов в нынешнем сезоне оказался такой: как разбить диск и какую файловую систему выбрать.

Общий ответ на первую половину вопроса дать невозможно, а варианты решения этой проблемы обсуждались столько раз, что повторять их было бы скучно. А потому перейдем сразу ко второй половине - о дисковой разметке я вскользь скажу в самом конце.

В качестве "родных" для Linux (то есть тех, на которые он может быть установлен и с которых способен стартовать) рассматриваются следующие файловые системы: ext2fs, ext3fs, ReiserFS, XFS, JFS. Именно они обычно и предлагаются на выбор при установке подавляющего большинства дистрибутивов. Конечно, существуют и способы установки Linux на файловые системы FAT/VFAT/FAT32, но это - только для тех медам и мсье, которые понимают толк в извращениях, и о них я говорить не буду.

Исключу из рассмотрения также JFS - по следующим причинам:

• малой распространенности среди пользователей Linux;
• недостаточности источников информации по ней (именно в Linux - для родной ОС AIX эта файловая система прекрасно документирована);
• моим лично слабым с ней знакомством.

Основными критериями при выборе файловой системы являются обычно надежность и быстродействие. В некоторых случаях приходится учитывать также фактор совместимости - в данном случае под ней понимается способность других операционок обращаться к той или иной файловой системе.

Начну рассмотрение с ReiserFS - потому что поводом к сочинению этой заметки послужил вопрос: а что следует считать маленькими файлами? Ведь общеизвестно, что именно эффективность работы с мелкими файлами является сильной стороной этой файловой системы.

Так вот, под мелкими файлами понимаются файлы размером меньше логического блока файловой системы, который в Linux в большинстве случаев равен четырем килобайтам, хотя и может задаваться при форматировании в некоторых пределах (зависящих от конкретной FS). Таких мелких файлов в любой Unix-подобной ОС - бессчетное количество. Типичным примером являются файлы, составляющие дерево портов FreeBSD, портежей Gentoo и тому подобных портообразных систем.

В большинстве файловых систем для таких минирофайлов существует как свой inode (информационный узел, содержащий метаинформацию о файле), так и блок данных, что приводит как к расходу дискового пространства, так и снижению быстродействия файловых операций. В частности, именно в этом причина катастрофической задумчивости файловой системы FreeBSD (как старой, UFS, так и новой, UFS2) при работе с собственной же системой портов.

В файловой системе ReiserFS в таких случаях отдельные блоки под данные не выделяются - она умудряется запихать данные файла непосредственно в область его же inode. За счет этого и дисковое пространство экономится, и быстродействие возрастает - буквально в несколько раз по сравнению со всеми прочими FS.

Такое обращение с мелкими файлами ReiserFS послужило причиной возникновения легенды о ее ненадежности. Действительно, при крахе файловой системы (то есть разрушении служебных областей) данные, размещенные совместно со своими inodes, вместе с ними же и пропадают - причем безвозвратно. Тогда как в тех файловых системах, где inodes и блоки данных всегда разобщены пространственно, последние теоретически можно восстановить. Так, для ext2/ext3 даже существуют средства, позволяющие это сделать.

Однако, как и всякая легенда, эта лишь производит впечатление достоверности. Во-первых, безвозвратная потеря данных относится лишь к очень маленьким файлам. Среди пользовательских таковых практически не бывает, а все прочие же легко восстанавливаются из дистрибутива.

Во-вторых, говоря о возможности восстановления данных из блоков, утуративших привязку к своим inodes, я не случайно употребил слово "теоретическая". Потому что на практике это занятие чрезвычайно трудоемкое, не дающее гарантированного результата. Каждый, кому приходилось этим заниматься, согласится, что предаться ему можно только от полной безысходности. И это относится ко всем файловым системам Linux. Так что этим аспектом при выборе файловой системы можно пренебречь.

По суммарному быстродействию ReiserFS однозначно быстрее всех остальных журналируемых FS, а по некоторым показателям превосходит и ext2. С результатами сравнения скорости выполнения некоторых распространенных файловых файловых операций можно ознакомиться здесь.

А вот с совместимостью у ReiserFS дело обстоит несколько хуже. Доступ к ней из ОС семейства Windows, насколько мне известно, невозможен. В некоторых операционках семейства BSD (DragonFlyBSD, FreeBSD) реализована поддержка этой файловой системы, но в режиме только для чтения. Даже вероятность того, что произвольный Linux LiveCD прошлых лет не имеет поддержку ReiserFS, не нулевая.

И тут впору вспомнить об ext3fs. Преимущество ее вовсе не в большей надежности - это такая же легенда, как и неустойчивость ReiserFS. О случаях краха ext3fs я слышал не меньше, чем об аналогичных происшествиях с ReiserFS. Самому мне не удавалось порушить ни ту, ни другую. Разве что с ext2 получалось - но и то очень давно, во времена ядра 2.2 (или даже еще 2.0).

Нет, главное преимущество ext3fs в ее совместимости - она с гарантией будет прочитана любой Linux-системой. Например, при восстановлении с какого-нибудь древнего подручного LiveCD - ситуация, практически не столь уж невероятная, мне приходилось в нее попадать. Опять же, большинство BSD-систем легко понимают ext3fs (хотя и без журналирования). Для Windows также имеются, насколько я знаю, всякого рода драйверы и plug-ins к распространенным файловым менеджерам (типа Total Commander), обеспечивающие доступ к разделам с ext2fs/ext3fs.

В отношении производительности ext3fs оставляет противоречивое впечатление. Во-первых, быстродействие ее очень зависит от режима журналирования, каковых предусмотрено три: с полным журналированием данных, частичным их журналированием и журналированием только метаданных. В каждом из режимов она показывает различную производительность на разных типах файловых операций. Впрочем, ни в одном случае быстродействие не является рекордным, в чем можно убедиться, пройдя по указанной выше ссылке.

Впрочем, если требование быстродействия ставится на первое место, то тут вне конкуренции оказывается ext2fs - правда, в этом случае придется смириться с отсутствием журналирования вообще. И, следовательно, с длительными проверками файловой системы при любом некорректном завершении работы - а при объемах современных дисков это может затянуться ой как надолго...

Относительно XFS можно сказать следующее. В плане совместимости к ней относится все то же самое, что написано для ReiserFS - более того, до некоторого времени она не поддерживалась стандартным ядром Linux. С точки зрения быстродействия она XFS она также не блещет, выступая суммарно примерно на одном уровне с ext3fs. А на операции удаления файлов вообще демонстрирует удручающую медлительность.

По моим наблюдениям, использование XFS оправдывает себя при работе не просто с большими, а с очень большими файлами - каковыми являются фактически только образы DVD и видеофайлы.

Возвращаюсь к вопросу о надежности. Банальное выключение питания в ходе обычной пользовательской работы, как правило, безболезненно переносят все журналируемые файловые системы (и ни одна из них не обеспечивает сохранности незаписанных на диск пользовательских операций - спасение утопающих и тут остается делом рук самих утопающих). Правда, для любой файловой системы можно смоделировать ситуацию, в ходе которой выключение питания приведет к более или менее серьезным ее повреждениям. Однако в реальной жизни возникновение таких ситуаций маловероятно. А полностью исключить их пожно приобретением источника бесперебойного питания - он придаст больше уверенности в сохранности данных, чем тип файловой системы. Ну а гарантией восстановления разрушенных данных в любом случае может быть только их регулярное резервное копирование...

Думаю, изложенной выше информации достаточно для осознанного выбора. Мой личный выбор в течении последних нескольких лет - ReiserFS. Изредка, на системах, где оправданно вынесение за пределы корневого раздела всего, чего только можно, целесолобразно использование ext3fs для корневой файловой системы и ReiserFS - для всех остальных.

Если предусматривается отдельный раздел под каталог /boot (а это рекомендуется при использовании загрузчика GRUB его разработчиками) - для него никакая другая файловая система, кроме ext2fs, не оправданна, какое-либо журналирование тут смысла не имеет. Наконец, если создается отдельный раздел под всякого рода мультимедийные материалы - тут можно подумать и о XFS.

Linux: создание файловых систем

2003 г

Создание файловых систем на дисковых разделах (или, в терминах DOS/Windows, форматирование последних) - второй этап подготовки диска к инсталляции Linux. Само по себе это действо - не из самых сложных, однако осознанное его выполнение требует некоторой подготовки.

Содержание

• Необходимое введение
• Устройство файловых систем Unix-семейства
• Файловые системы Linux
• Практические следствия

Необходимое введение

Термин "файловая система" - один из самых многозначных в компьютерной терминологии вообще, и в литературе, связанной с ОС Unix и ее клонами (а Linux именно к таковым и относится) - в особенности: больше значений имеет, пожалуй, только просто слово "система". Так сложилось исторически, и потому значение термина приходится определять по контексту. Мне таких значений известно как минимум пять, и нет уверенности, что это - все возможные значения.

Во-первых, файловой системой или, иногда, подсистемой, называют часть ядра, которая управляет организацией файлов и операциями над ними: в этом аспекте в одном ряду с файловой системой выступают система управления процессами и система ввода/вывода. Впрочем, именно это значение мы пока рассматривать не будем.

Во-вторых, и это специфично для Unix и Unix-подобных ОС, файловая система - универсальный интерфейс доступа ко всем ресурсам, как локальной машины, так и компьютеров, объединенных в сеть любого рода - от модемного подключения до спутникового канала. Собственно говоря, именно задействование такого интерфейса в некоей ОС и являет собой один из поводов для отнесения ее к семейству Unix-подобных.

В третьих, файловая система - это способ описания некоего физического устройства (обычно - дискового раздела). Именно это значение используется в термине "идентификатор типа файловой системы", о котором говорилось в статье о дисковых разделах. Он обычно специфичен для конкретной ОС, и потому здесь уместны термины: DOS-раздел, расширенный (Extended) раздел DOS, раздел Linux native и так далее. Хотя большинство всамделишних операционных систем способны тем или иным образом опознавать "неродные" для них идентификаторы и обращаться к данным на них. А в Linux в качестве "родных" (native) рассматривает дисковые разделы, идентифицированные целым рядом файловых систем в третьем понимании термина - от истинно родного Linux native до Extended DOS, включая логические тома (LVM) о которых говорилось в соответствующей статье, и программные RAID-массивы.

Здесь следует отметить, что помимо файловых систем физических (то есть надстраивающих реальные дисковые устройства, почему в этом контексте нередко фигурирует выражение - disk based file system), существуют и виртуальные файловые системы различных типов. К ним относятся и файловая система устройств - devfs, и временная файловая система в оперативной памяти - tmpfs, и procfs - система, ответственная за представление в виде файловой системы (уж простите за тавтологию) процессов. Иногда используются и файловые системы промежуточного типа, например, виртуальные диски (RAM-диски). Подобно tpmfs, они существуют только в оперативной памяти, однако в остальном ведут себя также, как и файловые системы disk-based.

В четвертых, под файловыми системами понимается внутренняя управляющая структура, позволяющая хранить, идентифицировать и отыскивать данные, ну и, конечно, манипулировать ими. Такие структуры, с одной стороны, специфичны для операционных систем, как FAT16 (со всеми ее вариациями типа VFAT или FAT32) для DOS, UFS для FreeBSD или Ext2fs - для Linux. С другой же - структуры управления файлами в ряде операционок строятся по близким принципам, чему ярким примером служат файловые системы Unix- и Unix-подобных ОС . И потому они могут быть объединены в одно семейство, противопоставляемое FAT-семейству, например.

Кроме того, Linux в настоящее время способен работать с управляющими структурами различных типов - от Ext3fs, являющей собой надстройку над традиционной Ext2fs, до XFS и JFS, разработанных первоначально для версий Unix от SGI и IBM, соответственно, а также ReiserFS. Нет запрета и на размещение Linux'а на файловой системе типа FAT (хотя и резонов к тому - нет также).

Добавлю, что в списке из предыдущего абзаца перечислены только файловые системы, способные нести базовые компоненты Linux, отвечающие за ее запуск и минимальную функциональность. Что же касается обмена данными - таковой возможен из Linux'а практически со всеми известными файловыми системами, хотя с некоторыми из них (например, NTFS или HPFS) - только в режиме чтения.

Наконец, в пятых, файловая система в Unix - это и логическая структура каталогов и файлов, которая объединяет и физические, и виртуальные файловые системы самых различных типов (например, дисковые разделы с файловыми системами Ext2fs и FAT16, виртуальные procfs, devfs и tmpfs), причем не только на локальной машине, но и и на любой удаленной. Структура эта - иерархическая, или древовидная, начинающаяся с корневого каталога, родительского по отношению ко всем прочим, от которого ответвляются отдельные файлы и дочерние каталоги, которые, в свою очередь, могут выступать как родительские по отношению к подкаталогам более глубоких уровней вложенности.

Положение дел в настоящий момент таково, что в Linux структура файловой системы обычно специфична для конкретного дистрибутива или их группы, связанной единством происхождения. Поэтому нередко можно столкнуться с такими выражениями, как файловая система Red Hat или Debian. Собственно, именно исторически сложившиеся различия в иерархии каталогов являются одним из критериев обособления нескольких линий дистрибутивов Linux. Как, впрочем, и потенциальной причиной их несовместимости. Однако можно надеяться, что усилиями стандартизирующих организаций, таких, как Linux Standard Base и Filesystem Hierarchy Standard, русский перевод стандарта - на сайте Виктора Костромина), увенчаются успехом, и можно будет говорить о единой логической файловой системы Linux, подобно тому, как это имеет место в ОС линии BSD.

В контексте настоящей статьи нас интересует только четвертый аспект файловых систем, то есть создание управляющих файлами структур, базируемых на дисках (вернее, их разделах).

Устройство файловых систем Unix-семейства

В этом разделе будет говориться о предметах, общих для всех Unix. Все файлы в Unix физически состоят из двух частей, реально локализованных в различных блоках дискового накопителя, но обязательно находящихся в одном дисковом разделе, первичном или логическом.

Первая часть файла - его т.н. метаданные, которые содержат файловый дескриптор (это просто некое уникальное число), сведения о его атрибутах (принадлежности, правах доступа, времени модификации и т.д.), а также информацию о том, в каких блоках дискового раздела (которые так и называются - блоки данных) физически размещено содержимое файла - те самые последовательности байтов, которые образуют доступный пользователю ASCII-текст или исполняемый модуль программы.

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

Так вот, суть процесса создания файловой системы на дисковом разделе (или, в понимании DOS/Windows, его форматирования) - в создании на нем суперблока (или, в некоторых файловых системах, нескольких его копий), списка inodes и отведении дискового пространства под блоки данных (а также загрузочного блока, о котором будет сказано ниже), а устройством этих дисковых областей определяются различия между файловыми системами различных типов. В результате на новом разделе образуется единственный файл - каталог корневого (для данной файловой системы) раздела (в некоторых случаях создается еще и каталог /lost+found, предназначенный для хранения нарушенных файлов).

Возникает вопрос, почему такой, казалось бы неотъемлемый, атрибут файла, как его имя, не обнаруживается ни в его метаданных, ни, тем более, среди его данных. Ответ прост: в Unix имя являет собой атрибут не файла, но файловой системы (в пятом, логическом, понимании термина). И для хранения имен файлов предназначены файлы особого типа - каталоги (в Unix есть и другие типы файлов, например, упомянутые выше файлы устройств). Они представляют собой просто списки файловых дескрипторов идентификаторов и соответствующих им имен файлов. Поэтому идущая от MacOS и активно используемая в Windows метафора каталога как папки с документами - в Unix только затемняет суть дела: здесь это скорее именно каталожный ящик в библиотеке.

Не смотря на столь простое устройство, роль каталогов в файловой системе Unix трудно переоценить: имена файлов, через которые они включаются в файловую систему (и через которые пользователь получает доступ к их содержимому), фигурируют только в составе каталога, к которому файл приписан - и больше нигде в системе. Так что удаление имени файла (или подкаталога) из списка, представляющего собой данные его родительского каталога (который, конечно, также имеет свой inode и файловый дескриптор, приписанный к каталогу, расположенному уровнем выше в иерархии файловой системы, и так далее) равносильно тому, что метаданные файла становится недоступными, а приписанные к его inode блоки данных помечаются как свободные. Именно так осуществляется удаление файла командой rm или файловым менеджером типа Midnoght Commander.

Нас, однако, сейчас интересует прямо противоположное - сделать файловую систему доступной. Из сказанного понятно, что для этого она со всем ее содержимым (суперблоком, списком inode, блоками данных) должна быть включена в состав какого-либо из существующих каталогов, называемого точкой монтирования. Именно это и составляет суть процесса монтирования. Результат же для монтируемой файловой системы - в том, что ее корневой каталог (до сих пор безымянный) получает имя каталога - точки монтирования (mount point), содержимое которого отныне составляет список имен ее файлов и подкаталогов. Обратный процесс - размонтирование, следствием чего является отсоединение от точки монтирования дерева смонтированной файловой системы. Кроме того, в inode ее корневого каталога устанавливается т.н. бит чистого размонтирования (clean bit). Впрочем, вопросам монтирования и размонтирования файловых систем будет посвящена специальная статья. Пока же рассмотрим особенности файловых систем, используемых в Linux'е.

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

Ext2fs

До недавнего времени список истинно родных (native) файловых систем для Linux ограничивался единственной - ext2fs (правда, Linux способен загрузиться и работать с FAT-раздела, но об этом мне даже не хочется говорить). Название это расшифровывается как "вторая расширенная файловая система"; "расширенная" она - по сравнению с файловой системой ОС minix, послужившей прототипом Linux, "вторая" - потому что ранние версии Linux базировались на Extfs с более ограниченными возможностями.

О файловой системе Ext2fs написано немало (см. дополнительные источники). Поэтому замечу только, что по способу организации хранения данных она - типичная представительница файловых систем Unix. Отличительная ее особенность - наличие нескольких копий суперблока, что повышает надежность хранения данных. Кроме того, для характерен очень эффективный механизм кэширования дисковых операций, что обеспечивает замечательное их быстродействие - едва ли не рекордное среди известных мне файловых систем. Оборотная сторона чего, однако, - относительно слабая устойчивость при аварийном завершении работы (вследствие мертвого зависания или отказа питания), поскольку отложенность записи изменений файлов делает весьма высокой вероятность нарушения связи между их inodes и блоками данных.

Конечно, времена, когда некорректный останов Linux-машины грозил полным разрушением файловой системы, остались в далеком прошлом. Однако в любом случае останов системы без штатного размонтирования файловых систем приводит к тому, что в них не устанавливается упомянутый выше "бит чистого размонтирования". А без этого утилиты обслуживания диска (такие, как программа проверки fsck) при перезагрузке не воспринимают их как целостные и начинают проверку, которая при современных объемах дисков может занять немалое время.

О журналируемых файловых системах

Проблема нарушения целостности файловой системы при некорректном завершении работы в большей или меньшей мере характерна для всех ОС семейства Unix. И потому с давних пор в них разрабатываются т.н. журналируемые файловые системы. Журнал -- это нечто вроде log-файла дисковых операций, в котором фиксируются не выполненные, а только предстоящие манипуляции с файлами, вследствие чего оказывается возможным самовосстановление целостности файловой системы после сбоя.

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

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

Текущие версии ядра Linux поддерживают в качестве нативных четыре журналируемые файловые системы: ReiserFS и Ext3fs, специфичные для этой ОС, XFS и JFS - результаты портирования в Linux файловых систем, разработанных первоначально для рабочих станций под ОС Irix (SGI) и AIX (IBM), соответственно. Правда, широкое признание получили только три первых, так что о JFS я пока говорить не буду.

ReiserFS

Файловая система ReiserFS оказалась для Linux исторически первой из журналируемых - она поддерживается каноническим ядром c http://www.kernel.org, начиная с первых версий ветви 2.4.x (в настоящее время существуют патчи, позволяющие использовать ее и с версиями ветви 2.2.xx). И была единственной, разработанной "с нуля" специально для этой ОС Хансом Райзером и его фирмой Namesys. Как и в большинстве рассмотренных, в ReiserFS осуществляется журналирование только операций над метаданными файлов. Что, при определенном снижении надежности, обеспечивает высокую производительность: по моим наблюдениям, на большинстве типичных пользовательских задач она лишь незначительно уступает Ext2fs. А на такой, достаточно обычной, операции, как копировании большого количества мелких файлов, существенно ее опережает.

Кроме этого, ReiserFS обладает уникальной (и по умолчанию задействованной) возможностью оптимизации дискового пространства, занимаемого мелкими, менее одного блока, файлами (а следует помнить, что в любой Unix-системе такие файлы присутствуют в изобилии): они целиком хранятся в своих inode, без выделения блоков в области данных - вместе с экономией места это способствует и росту производительности, так как и данные, и метаданные (в терминах ReiserFS - stat-data) файла хранятся в непосредственной близости и могут быть считаны одной операцией ввода/вывода.

Вторая особенность ReiserFS - то, что т.н. хвосты файлов, то есть их конечные части, меньшие по размеру, чем один блок, могут быть подвергнуты упаковке. Этот режим (tailing) также включается по умолчанию при создании ReiserFS, обеспечивая около 5% экономии дискового пространства. Что, правда, несколько снижает быстродействие, и потому режим тайлинга можно отменить при монтировании файловой системы. Однако упаковка хвостов автоматически восстанавливается после перекомпиляции ядра - что, как будет сказано чуть ниже, требует внимательного отношения.

ReiserFS не совместима с Ext2fs на уровне утилит обслуживания файловой системы. Однако соответствующий инструментарий, объединенный в пакет reiserfsprogs, уже давно включается в штатный комплект современных дистрибутивов.

Более серьезная проблема с совместимостью - в том, что распространенные загрузчики Linux (и Lilo, и GRUB - хотя и по разным причинам) часто не способны загрузить ядро Linux с раздела ReiserFS, оптимизированного в режиме тайлинга. А поскольку, будучи отключен, этот режим обладает свойством самовосстановления, пользователь может столкнуться с тем, что после пересборки ядра система просто откажется загружаться. Именно поэтому выше я упоминал, что создание раздела под каталог /boot может быть необходимым.

Ext3fs

В отличие от ReiserFS, Ext3fs - не более чем журналируемая надстройка над классической Ext2fs, разработанная Стивеном Твиди в компании Red Hat и поддерживаемая ядром Linux, начиная с версии 2.4.16. Как следствие такого происхождения, она сохраняет со своей прародительницей полную совместимость, в том числе и на уровне утилит обслуживания (начиная с версии 1.21 объединяющего их пакета e2fsprogs). И переход от ext2fs к ext3fs может быть осуществлен простым добавлением файла журнала к первой, не только без переформатирования раздела, но даже и без рестарта машины.

Из этого вытекает первое преимущество ext3fs, особенно весомое в случае большого парка компьютеров. Второе же - чуть ли не максимальная надежность: ext3fs является единственной системой из рассматриваемых, в которой возможно журналирование операций не только с метаданными, но и с данными файлов.

В Ext3fs предусмотрено три режима работы - полное журналирование (full data journaling), журналирование с обратной записью (writeback), а также задействуемое по умолчанию последовательное (ordered).

Режим полного журналирования, как легко догадаться из названия, распространяется и на метаданные, и на данные файлов. Все их изменения сначала пишутся в файл журнала и только после этого фиксируются на диске. В случае аварийного отказа журнал можно повторно перечитать, приведя данные и метаданные в непротиворечивое состояние. Этот механизм практически гарантирует от потерь данных, однако является наиболее медленным.

В режиме отложенной записи, напротив, в файл журнала записываются только изменения метаданных файлов, подобно всем рассмотренным ниже файловым системам. То есть никакой гарантии сохранности данных он не предоставляет, однако обеспечивает наибольшее (в рамках Ext3fs) быстродействие.

В последовательном режиме также физически журналируются только метаданные файлов, однако связанные с ними блоки данных логически группируются в единый модуль, называемый транзакцией (transaction). И эти блоки записываются перед записью на диск новых метаданных на диск, что, хотя и не гарантирует сохранности данных, весьма последней способствует. Причем - при меньших накладных расходах по сравнению с полным журналированием, обеспечивая промежуточный уровень быстродействия.

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

XFS

Файловая система XFS, в отличие от молодых ReiserFS и ext3fs, развивается для фирмой SGI на протяжении почти десяти лет - впервые она появилась в версии Irix 5.3, вышедшей в 1994 г. Но в Linux она была портирована лишь недавно (текущая ее версия - 1.1, свободно доступна с сайта SGI's XFS page - http://oss.sgi.com/projects/xfs) и по сию пору не поддерживается официальным ядром.

XFS - единственная 64-разрядная файловая система из рассмотренных. Однако уникальность ее - не только в этом. Особенностями XFS являются:

• механизм allocation group, то есть деление единого дискового раздела на несколько равных областей, имеющих собственные списки inodes и свободных блоков, для распараллеливания дисковых операций;
• логическое журналирование только изменений метаданных, но - с частым сбросом их на диск для минимизации возможных потерь при сбоях;
• механизм delayed allocation - ассигнование дискового пространства при записи файлов не во время журналирования, а при фактическом сбросе их на диск, что, вместе с повышением производительности, предотвращает фрагментацию дискового раздела;
• списки контроля доступа (ACL, Access Control List) и расширенные атрибуты файлов (extended attributes), рассмотрение которых далеко выходит за рамки нынешней темы.

В результате XFS предстает как очень сбаллансированная файловая система: она почти столь же надежна, как Ext3fs, и не очень уступает ReiserFS в быстродействии на большинстве файловых операций. А при манипуляциях с (очень) большими файлами XFS - просто вне конкуренции: как легко догадаться по имени фирмы-разработчика, она ориентирована на работу с мультимедийными приложениями с их огромными потоками данных. Не отмечалось для нее и проблем с совместимостью.

Все сказанное позволяет сделать вывод, что XFS - оптимальная файловая система для Linux. Однако следует учесть: в отличие от ReiserFS и ext2fs, поддержка которых является штатными опциями ядра Linux, XFS по сию пору (текущая версия - 2.4.19) не поддерживается каноническим ядром Линуса Торвальдса (тем, которое можно получить с http://www.kernel.org). Хотя недавнее включение такой поддержки в разрабатываемую ветвь ядра (версии 2.5.X) позволяют надеяться, что скоро эта функция станет штатной.

Возможность работы с XFS обеспечивает специальный патч (xfs-2.4.1X-all-i386.bz2), который можно получить с сайта SGI вместе с соответствующими утилитами поддержки: традиционные средства e2fsprogs, для XFS не пригодны. Утилиты поддержки для XFS объединены в несколько пакетов, из которых абсолютно необходимым является xfsprogs. Обо всем этом следует помнить при предварительной разметке диска.

Критерии выбора

Таким образом, каждая из четырех рассмотренных файловых систем имеет свою уникальную положительную особенность (даже Ext2fs - как бы то ни было, лидером по суммарному быстродействию остается она), и как минимум один недостаток (который, тем не менее, не служит препятствием к ее использованию). Так что выбор файловой системы должен определяться задачами пользователя и характером преобладающих его данных.

Кроме этого, если, как рассказывалось в статье про LVM, максимально разгрузить корневую файловую систему, выделив в логические тома отдельные ее ветви, возможно и комбинированное использование файловых систем. То есть подбор для каждого из дисковых разделов наиболее подходящей к его содержанию управляющей структуры.

Так, ранее неоднократно говорилось, что Ext2fs - наиболее подходящий выбор для загрузочного раздела (а при использовании в качестве загрузчика GRUB - это почти обязательное требование). Кроме того, Ext2fs вполне подходит для таких ветвей, как /tmp или /var. Для первого, по определению, устойчивость к сбоям не критична. Для второго же определяющим требованием является быстродействие (так, в Source Based дистрибутивах типа Gentoo /var задействуется для хранения временных продуктов компиляции, и быстродействие файловых операций в нем несколько способствует ускорению сборки пакетов). Наконец, на настольной машине Ext2fs можно применить и для корневой файловой системы - ведь при дробном разбиении диска в корне остается минимум редко изменяемых компонентов.

С другой стороны, корень - наиболее критичный в отношении устойчивости элемент файловой системы. И потому оптимальным для него представляется файловая система Ext3fs, как наиболее устоявшаяся. Кроме того, в экстремальных ситуациях она может быть без проблем смонтирована как Ext2fs. Для разделов типа /usr и /usr/local Ext3fs также видится вполне подходящим вариантом.

Наиболее важная часть файловой системы настольной машины с точки зрения пользователя - его, пользовательские, данные, то есть каталог /home (ибо систему можно переустановить, а вот потеря данных может быть невосполнимой). Однако это - и наиболее изменяемая ее часть, что предъявляет высокие требования к быстродействию файловых операций. И поэтому Ext3fs - не лучшее (ИМХО) решение для каталога /home, более целесообразно разместить здесь какую-либо из "быстрых" журналируемых файловых систем, ReiserFS или XFS. Выбор между ними определяется личными предпочтениями и характером данных (пользуясь случаем, замечу, что быстродействие JFS, по моим наблюдениям над типичными пользовательскими манипуляциями, оставляет желать лучшего).

Очевидно, что быстродействие XFS при работе с файлами (очень) большого размера делает ее предпочтительной, если речь идет об обработке изображений, мультимедийном контенте, картографической информации и т.д. В то же время преимущества ReiserFS сказываются в основном при работе с файлами (очень) маленького размера (менее блока файловой системы), каковых среди пользовательских данных обычно бывает мало. И потому мое личное мнение однозначно - и высказывается в пользу XFS. К тому же собственный опыт общения с ReiserFS был неблагоприятен, особенно в сочетании с технологией LVM. XFS же, напротив, по моим впечатления идеально с ней гармонирует.

Подведем итог - оптимальной мне видится следующее сочетание файловых систем:

• Ext3fs - для корневого каталога (/) и каталога /usr (а также /usr/local и /usr/X11R6, если таковые обособляются в отдельные ветви);
• Ext2fs - для загрузочного /boot, каталогов /tmp и /var;
• XFS - для раздела под домашние каталоги (/home).

Повторяю, это лишь мое мнение, основанное на опыте настольного применения Linux - для серверов различного рода оно силы не имеет.

Практические следствия

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

Обычно при установке Linux создание файловых систем - компетенция инсталлятора, который осуществляет его с некоторыми опциями по умолчанию. В контексте рассмотренного в предыдущем разделе ясно, что опции эти не всегда будут лучшими с точки зрения пользователя. Изменить же характеристики, определенные для файловой системы при ее создании, невозможно без повторного выполнения этого процесса (и, соответственно, потери данных). Однако все SB-дистрибутивы допускают ручное вмешательство в процедуру создания файловой системы, а в Gentoo, например, это - просто единственный способ ее выполнения.

Файловая система Ext2fs может быть создана любой из следующих команд - /sbin/mke2fs, /sbin/mkfs, /sbin/mkfs.ext2 с указанием файла устройства в качестве аргумента, например:

$ /sbin/mke2fs /dev/hd?#

Каждая из этих команд (а /sbin/mkfs.ext2 - обычно символическая ссылка на /sbin/mke2fs) имеет ряд опций, как то: -b для определения размера блока файловой системы (возможные значения - 1024, 2048 или 4096 байт, по умолчанию принято последнее),-c для проверки испорченных участков диска, -N и -i для задания числа inodes и количества байт на один узел, соответственно; с деталями можно ознакомиться на соответствующей man-странице, например, man (8) mke2fs.

Для создания файловой системы ext3fs можно применить ту же команду mke2fs с опцией -j, при этом случае она получит некоторые "умолчальные" характеристики. Определить же их вручную позволяет следующая форма этой команды:

$ /sbin/mke2fs -J опции_журналирования /dev/hd?#

Возможные значения опций журналирования - size=размер, задающая объем журнального файла в мегабайтах, и device=внешний_журнал подключения новой файловой системы к журналу, ранее созданному на другом дисковом разделе.

Можно использовать и специальную команду /sbin/mkfs.ext3 - возможности ее идентичны таковым /sbin/mke2fs (ибо она ни что иное, как символическая на нее ссылка). Но самое интересное - возможность преобразования существующей ext2fs в ext3fs простым добавлением журнала, не только без потери данных, но и без перезапуска системы (и даже без размонтирования). Делается это командой

$ tune2fs -j /dev/hd?#

Она просто добавляет файл журнала /.journal в корневом каталоге модифицируемой файловой системы (если последняя не была размонтирована), или задействует для журнала скрытый inode (если перед модификацией файловая система была размонтирована). Добавлю, что обратное преобразование - еще проще, и осуществляется командой монтирования (о чем будет говориться в следующей статье).

Файловая система ReiserFS создается специально предназначенной для этого командой - /sbin/mkreiserfs из пакета reiserfsprogs. Для нее доступны многочисленные опции (-s для задания размера журнала, -f для принудительного переформатирования ранее существовавшей файловой системы иного типа, и т.д.), с которыми можно ознакомиться посредством man (8) mkreiserfs. И во избежание неожиданностей напомню: если корневой раздел форматируется как ReiserFS, не лишним будет предусмотреть небольшой раздел под каталог /boot для размещения на нем файловой системы ext2fs.

Для создания XFS также существует собственная команда mkfs.xfs (из пакета xfsprogs). В ней предусмотрено несколько опций, каждая из которых имеет ряд субопций, принимающих численные значения. Важнейшие из них:

• -b, которая посредством субопции size=## позволяет задать размер блока данных в байтах, который должен быть кратен размеру страницы оперативной памяти (для платформы i386 - 4 Кбайт) и может варьировать в диапазоне от 512 до 65536 (по умолчанию - 4096);
• -d, определяющая параметры области данных файловой системы, такие, как количество самостоятельных областей раздела (Allocation groups, субопция agcount), или, напротив, их размер (субопция agsize);
• -l, специфицирующая параметры журнального файла, например, его размер (субопция size).

При использовании mkfs.xfs для достижения максимальной производительности рекомендуется в явном виде задать количество allocation groups - иначе оно будет определяться автоматически, что ведет к непроизводительным расходам ресурсов. Это делается из расчета - одна allocation group на 4 Гбайт дискового пространства. Далее можно установить размер файла журнала - здесь рекомендованное значение составляет 32 Мбайт. То есть для дискового раздела объемом в 20 Гбайт команда приобретет вид

$ mkfs.xfs -d agcount=5 -l size=32m /dev/hda1

Кроме всех перечисленных, команда mkfs.xfs имеет опцию -f (от force) - принудительное создание файловой системы XFS поверх любой существующей. Ее достаточно, если последняя была ext2fs (и, исходя из общих соображений, ext3fs, хотя я этого не проверял). Если же XFS создается поверх ReiserFS - после этого возможны ошибки при монтировании новой файловой системы. Впрочем, то же относится и к обратной процедуре (замене XFS на ReiserFS), а также, если любая из этих "продвинутых" файловых систем заменяется на разделе системой ext2fs. Они связаны с тем, что команда монтирования может распознать новосозданную XFS как дефектную ReiserFS, и наоборот.

Во избежание этого перед таким замещением приходится прибегать к несколько шаманскому приему - обнулению начальных областей раздела (хранящего метаданные файловой системы) командой

$ dd if=/dev/zero of=/dev/hd?#

Ждать заполнения нулями всего устройства не обязательно - достаточно дать этой команде поработать секунд 10-20, после чего прервать ее комбинацией клавиш Control+D и перейти к созданию новых файловых систем.

И последнее, о чем следует сказать - о swap-разделе, созданном на этапе разбиения диска. Хотя файловой системы как таковой он не несет, но нуждается в определении, что достигается командой

$ mkswap имя_устройства

к которой следует подходить со вниманием - применение ее к обычному разделу уничтожит на нем все данные.

Библиография вопроса

Многие сложные вопросы устройства файловых систем в этой статье были затронуты лишь вскользь. За более подробной информацией по ним следует обратиться к дополнительным источникам. Так, общая организация файловой системы Unix рассматривается во многих руководствах по этой операционной системе, например: С. Д. Кузнецов. Операционная система UNIX.

Устройство файловой системы ext2fs подробно описано в статье Виктора Хименко "Файлы, файлы, файлы" (Мир ПК, 2000, №2-3 - часть 1; часть 2).

Подробное описание современных журналируемых файловых систем, используемых в Linux, дано в цикле статей Дэниела Роббинса, русский перевод которого, выполненный Владимиром Холмановым, доступен здесь.

DragonFly: монтирование образов CD- и DVD-дисков

26 апреля 2005 г

Как известно, образы для записи CD- и DVD-дисков во всех Linux'ах и BSD'ях создаются посредством утилиты mkisofs. После чего и записываются тем или иным образом:-) (cdrecord там, или burncd). Однако нередко, прежде чем портить болванку, возникает желание посмотреть - а то ли собрано в образ, что нужно?

В Linux'ах это делается посредством монтирования loop-устройства. Во FreeBSD 5-й ветки - с помощью доступа к универсальному устройству md (Memory Disk), как это было описано ранее. DragonFly же унаследовал от FreeBSD 4-й ветки понятие псевдоустройства vn (Virtual Node). Поскольку многие уже могли забыть, что это такое (а начинающие пользователи - и не знать никогда), позволю им (и себе не в последнюю очерерь) вкратце напомнить, как это делается.

Для начала нужно обеспечить поддержку псевдоустройтсва vn. Она может быть встроена в ядро - по умолчанию в ядре GENERIC ее нет, - для чего из файла /usr/src/sys/i386/conf/LINT в файл конфигурации текущего ядра нужно перетащить строку

pseudo-device vn #Vnode driver (turns a file into a device)

и выполнить пересборку, как это было описано здесь.

Однако делать это отнюдь не обязательно - псевдоустройство vn поддерживается и модульно, а все возможные модули в DragonFly собраны по умолчанию. Так что достаточно подгрузить нужный

S kldload vn

чтобы поддержка Virtual Nodes стала реальностью. После чего остается только поставить в соответствие определенному /dev/vn# файл ранее созданного образа диска. Это делается специальной утилитой

$ vnconfig /dev/vn0 /path_to/filename.iso

где /dev/vn0 - имя файла псевдоустройства (очевидно, что в качестве номера может быть использован любой наличный в каталоге /dev и ранее не задействованный). Каковое и монтируется самым обычным образом:

$ mount -t cd9660 /dev/vn0 /mnt/iso

Теперь состав собранного образа можно просмотреть командами типа ls или в любом файловом менеджере. И, убедившись в правильности сборки, размонтировать

$ umount /mnt/iso

и отправить на запись.