система ufs что это
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
UFS (Unix File System)
| Полное название | UNIX file system |
|---|---|
| Содержимое каталога | table |
| Limits | |
| Макс. размер тома | 2 73 байт (8 Збайт) |
| Макс. размер файла | 2 73 байт (8 Збайт) |
| Макс. длина имени файла | 255 байт |
| Другие | |
| Операционная система | A/UX, DragonFlyBSD, FreeBSD, FreeNAS, NAS4Free, HP-UX, NetBSD, Linux, OpenBSD, Solaris, SunOS, Tru64 UNIX, UNIX System V, and others |
Хотя вообще говоря, UFS расшифровывается просто как файловая система Unix (Unix File System). И под этим именем известны и файловые системы других ОС этого семейства, отнюдь не идентичные UFS из FreeBSD. Так что некоторая неопределенность терминологии имеет место быть
Поддержка данной файловой системы имеется также в ядре Linux и операционной системе Solaris.
Файловая система UFS содержит четыре основных компонента с управляющей информацией: загрузочный блок, суперблок, таблицу индексных дескрипторов (i-node table) и каталоги. Кроме этого, в Solaris (начиная с версии 2.52, с 1995 года) в файловой системе хранятся списки управления доступом (ACL). Хранение списков ACL обеспечивают так называемые теневые индексные дескрипторы (shadow inodes).
Преимущество UFC заключается в локализованной связи блоков данных и метаданных в одной и той же группе цилиндров, а в идеале, всего содержимого каталога (как данных, так и метаданных для всех файлов), в той же группе, таким образом, уменьшена фрагментация вызванных рассеянием содержимого каталогов диска. Некоторые из этих характеристик в суперблоке включали количество дорожек и секторов, скорость вращения диска, скорость головки. В полностью оптимизированной системе, головка может быть перемещена между соседними дорожками для чтения разбросанных секторов из чередующихся слоях дорожек.
Содержание
Устройство UFC
Файловая система состоит из:
Файловая система UFS обладает следующими особенностями:
Флаги состояния. Показывают состояние файловой системы как чистое, стабильное, активное или неизвестное. Наличие флагов состояния исключает проведение дополнительных (излишних) проверок файловой системы. Если файловая система чистая или стабильная, то утилита проверки файловой системы под названием fsck (file system check) не запускается при загрузке системы.
Большие файловые системы. Файловая система UFS может иметь размер до I Тбайт и содержать стандартные файлы размером до 2 Гбайт. По умолчанию системное программное обеспечение Solaris не поддерживает расслоение дисков, которое требуется для формирования логических частей диска, достаточно больших для файловой системы размером в 1 Тбайт. Эту возможность предоставляют необязательные пакеты программного обеспечения, такие как Solstice DiskSuite.
Необходимость в создании (или в пересоздании) файловой системы UFS возникает только в тех случаях, когда вы выполняете одну из следующих операций:
Загрузочный блок (boot block). Хранит информацию, которая используется при выполнении загрузки системы. Загрузочный блок хранит процедуры, используемые при выполнении загрузки системы. Без загрузочного блока система не загружается. Если файловая система не используется при загрузке системы, загрузочный блок остается пустым. Загрузочный блок появляется только в первой группе цилиндров (группа 0) и занимает первые 8 Кбайт части диска.
Суперблок (superblock). Хранит важную информацию о файловой системе.
Индексный дескриптор (inode). Хранит всю информацию о файле за исключением его имени.
Блок хранения, или блок данных. Хранит данные каждого файла.
UFC использует следующие подходы для увеличения производительности системы:
Содержание inode UFS
Во многих UFS если после создания файла в кластер ничего не писалось (например, после открытия файла переместили указатель далеко-далеко и что-то туда записали), то под этот кластер не отводится место, а ссылке, которая должна на него указывать, присваивается 0 (это особенно актуально в свете использования hash-таблиц, которые обычно имеют внутри себя пустое пространство). То же самое делается если кластер оказывается заполнен нулями (незаполненное место считается залитым нулями).
История создания и развития UFS
После 4.4BSD и BSD Unix системы разделились, появились такие системы, как FreeBSD, NetBSD, OpenBSD и DragonFlyBSD. Таким образом были созданы UFS1 и UFS2, которые представляют собой два слоя — верхний слой, который обеспечивает структуру каталогов и поддерживает метаданные в индексном дескрипторе структуры, и нижних слоев, которые позволяет представлять контейнерные данные как индексные дескрипторы. Это было сделано для поддержки как традиционной FFS, так и LFS.
Со временем в связи с постоянно увеличивающимися объёмами дисковых накопителей и переводу адресации дискового пространства на Advanced Format во FreeBSD размер блока файловой системы, принятый по умолчанию, увеличен с 16 КБ до 32 КБ, а размер фрагмента — с 2 КБ до 4 КБ. Эта оптимизация повысила производительность дисковых операций ввода-вывода на дисковых накопителях с ёмкостью порядка 1 ТБ с размером сектора 4 КБ. Максимально возможный размер блока на файловой системе UFS2/FFS составляет 64 КБ.
Linux поддерживает UFS на уровне чтения, но не имеет полной поддержки для записи UFS. Родной Linux ext2 создан по подобию UFS (в некоторых 4.4BSD системах UFS слой может использовать ext2 слой как контейнер, так же, как он может использовать FFS и LFS).
Unix File System
Unix File System (UFS) — файловая система, созданная для операционных систем семейства BSD и используемая в переработанном и дополненном виде на данный момент как основная в операционных системах-потомках (FreeBSD, OpenBSD, NetBSD).
Поддержка данной файловой системы имеется также в ядре Linux и операционной системе Solaris.
Содержание
Геометрия
Физически UFS состоит из следующих частей:
Индексные дескрипторы нумеруются последовательно. Несколько первых индексных дескрипторов сохранены по историческим причинам, далее следуют индексные дескрипторы корневого каталога.
Каталог файлов содержит только список файлов в директории и индексный дескриптор, связанный с каждым файлом. Все метаданные файла хранятся в индексном дескрипторе.
История и развитие
Ранние версии Unix использовали файловую систему, называвшуюся просто «FS». FS включала в себя только загрузочные блоки, суперблок, множество индексных дескрипторов и блоки данных. Это хорошо работало на дисках небольшого размера, которые производились во времена ранних Unix. Но технологии развивались, диски становились больше, индексных дескрипторов и блоков данных становилось слишком много. Тогда FS был оптимизирован и перерос в FFS (Fast File System), в котором появились группы цилиндров, каждая из которых обладала собственным индексным дескриптором и позволяла избегать получающейся «свалки».
Цель FFS заключается в том, чтобы попытаться локализовать связь блоков данных и метаданных в одной и той же группе цилиндров, а в идеале, всё содержимое каталога (как данных, так и метаданных для всех файлов), в той же группе, таким образом, уменьшив фрагментацию вызванных рассеянием содержимого каталогов диска.
Некоторые из этих характеристик в суперблоке включали количество дорожек и секторов, скорость вращения диска, скорость головки. В полностью оптимизированной системе, головка может быть перемещена между соседними дорожками для чтения разбросанных секторов из чередующихся слоях дорожек.
С увеличением размеров дисков уровень оптимизации стал не столь эффективен (в частности, с дисками, которые используют линейные сектора нумерации и переменных секторов на дорожке). С увеличением дисков и файлов, чтение фрагментированых кусков стало сложнее. Чтобы бороться с этим, BSD первоначально увеличил размер блока файловой системы от одного сектора до 1 КБ в 4.0BSD, и, в FFS до 8 КБ. Число блоков, представимых с фиксированной (битной) шириной блока, увеличили (разрешение для больших дисков). С увеличением размера блока, диски с большим количеством маленьких файлов будут занимать много места. Для решения проблемы неэффективного использования свободного пространства в слой FFS файловой системы UFS2 был добавлен уровень фрагментов, представляющих собой способ адресации отдельных частей блока данных — фрагментов.
В связи с постоянно увеличивающимися объёмами дисковых накопителей и переводу адресации дискового пространства на Advanced Format во FreeBSD размер блока файловой системы, принятый по умолчанию, увеличен с 16 КБ до 32 КБ, а размер фрагмента — с 2 КБ до 4 КБ. Эта оптимизация повысила производительность дисковых операций ввода-вывода на дисковых накопителях с ёмкостью порядка 1 ТБ с размером сектора 4 КБ. Максимально возможный размер блока на файловой системе UFS2/FFS составляет 64 КБ.
Применение
Пользователи некоторых коммерческих Unix систем, таких как Solaris, HP-UX и Tru64 UNIX, приняли UFS. Большинство из них перевели системы на UFS, добавили проприетарные дополнения, которые позволяли не распознать UFS пользователям других версий UNIX. Удивительно, но многие из них продолжают использовать оригинальный размер блока данных и ширину блока, как и в оригинальной UFS, так что некоторая степень совместимости на разных платформах остается. Совместимость между реализациями неполная, в лучшем случае, и должна быть исследована перед использованием на нескольких платформах.
В Solaris 7, Sun Microsystems включили UFS Logging, которое принесло журналируемость файловой системы в UFS. Solaris UFS так же включало дополнения для файлов и дисков больших размеров. Начиная с Solaris 10, пользователю предоставляется выбрать при установке UFS или ZFS (усовершенствованную файловую систему от Sun). В OpenSolaris UFS полностью заменена на ZFS.
После 4.4BSD и BSD Unix системы разделились. Появились такие системы, как FreeBSD, NetBSD, OpenBSD и DragonFlyBSD. Возникают UFS1 и UFS2, которые представляют собой два слоя — верхний слой, который обеспечивает структуру каталогов и поддерживает метаданные (разрешения, права доступа и т. д.) в индексном дескрипторе структуры, и нижних слоев, которые позволяет представлять контейнерные данные как индексные дескрипторы. Это было сделано для поддержки как традиционной FFS, так и LFS. Верхний слой называется «UFS», и нижние слои называются «FFS» и «LFS».
Linux поддерживает UFS на уровне чтения, но не имеет полной поддержки для записи UFS. Родной Linux ext2 создан по подобию UFS. (В самом деле, в некоторых 4.4BSD системах, UFS слой может использовать ext2 слой как контейнер, так же, как он может использовать FFS и LFS).
NeXTStep, которая возникла из BSD, также использует версию UFS. В созданной в Apple Mac OS X, UFS доступна как альтернатива HFS+. Однако, как и в Mac OS X v10.5, нельзя установить Mac OS X «Leopard» на UFS-форматированный раздел. Кроме того, нельзя обновить старые версии Mac OS X, установленые на UFS, на Leopard; модернизация требует переформатирования раздела.
Игровая консоль PlayStation 3 использует UFS2 на своём HDD. В PlayStation 2 используется UFS. [3]
FreeBSD: физика файловой системы UFS
Алексей Федорчук
2004-2005 гг
В настоящей заметке речь пойдет о способе физической организации блоков дискового раздела, обеспечивающем возможность записи, хранения и манипулирования файлами, специфичном для FreBSD, точнее, для её файловых систем UFS и UFS2, бывших единственно нативными в этой ОС до портирования ZFS.
Вступление
Файловая система FreeBSD принадлежит к Unix-семейству файловых систем и обладает множеством общих для всех них черт. Она носит название UFS, в 5-й ветке используется ее усовершенствованная разновидность — UFS2. Для начала рассмотрим общие принципы устройства той и другой, а потом обратимся к рассмотрению особенностей, свойственных UFS2.
Для файловой системы FreeBSD (и вообще BSD-систем, начиная с 4.2BSD) можно встретить и еще одно наименование — FFS (Fast File System). Для понимания соотносимости этих терминов необходимо обратиться к истории…
Изначальная файловая система Unix носила имя s5fs (то есть файловая система System V). По свидетельству современников, была она отменно медленной, да еще и не допускала имен файлов из более чем 14 символов. А поскольку в те времена в Университете Беркли также разрабатвалась версия Unix (именовавшаяся BSD Unix — предтеча всех современных BSD-систем), то решили поправить дело. И создали файловую систему, названную FFS (где Fast означало ее быстроту сравнительно с s5fs).
Поскольку разработки Берклианцев изначально (еще до того, как RMS придумал Open Sources и Free Software Foundation) были свободными, разработчики первозданного Unix’а не погнушались включить поддержку FFS в очередную версию канонической System V. А уже от нее и произошло большинство современных файловых систем Unix’ов, как проприетарных, так и свободных. И UFS — одна из таких реализаций, включающей элементы виртуальной файловой системы, vfs/vnode (по крайней мере, именно так трактует эти понятия Ю.Вахалия в своей книге «Unix изнутри»). А UFS2, как легко догадаться, — усовершнествованная 64-разрядная версия последней.
Хотя вообще говоря, UFS расшифровывается просто как файловая система Unix (Unix File System). И под этим именем известны и файловые системы других ОС этого семейства, отнюдь не идентичные UFS из FreeBSD. Так что некоторая неопределенность терминологии имеет место быть…
Как было выяснено в ранее, логический дисковый раздел (часть слайса) — это, говоря метафорически, группа смежных цилиндров, разбитых на физические блоки по 512 байт. Однако специфика файловых систем BSD-клана заключается в том, что реально она делится еще и на части фиксированного объёма (зависящего от объема раздела). Это т.н. группы цилиндров (условно назовем ее внутренней), каждая из которых имеет включает четыре самостоятельные части:
Рассмотрение их целесообразно начать с конца списка, то есть с области данных.
Блоки данных
Область данных (она занимает подавляющий объем пространства каждой группы цилиндров) образована блоками файловой системы. Подобно физическому блоку, блок файловой системы (именуемый также блоком логическим) представляет собой квант информации, доступный за одну операцию чтения/записи, но уже не дисковой головки, а операционной системы. Очевидно, что логический блок не может быть меньше блока физического (то есть 512 байт), и размер его обязательно кратен целому числу последних.
Понятие логического блока введено для повышения производительности дисковых операций. Не требует доказательства утверждение, что скорость обмена данными квантами по 1 Кбайт будет выше, чем 512-байтными, 2-килобайтными — еще быстрее, и так далее. И потому с точки зрения быстродействия файловых операций выгоден максимальный размер логического блока файловой системы.
С другой стороны, увеличение размера логического блока ведет к непроизводительному расходу дискового пространства за счет т.н. внутренней фрагментации данных. Ее не следует путать с внешней фрагментацией, для борьбы с которой на файловых системах FAT-семейства были в свое время мобилизованы всякого рода speeddisk’и с комбатантами: вследствие особенностей алгоритмов управления данными файловые системы Unix-семейства настолько мало подвержены внешней фрагментации, что о преодолении оной вообще практически не говорят.
Внутренняя же фрагментация выражается в том, что данные файлов, размер которых меньше блока файловой системы, все равно занимают его целиком. Также целый блок потребуется и для хранения файловых хвостов, то есть остатков сверх объема, кратного размеру логического блока. Для борьбы с фрагментацией в UFS, пардон за тавтологию, введено понятие фрагмента — логической части блока файловой системы, которая может быть записана или считана независимо от остальной его части.
Ясно, что размер фрагмента все равно не может быть меньше физического блока. При этом UFS накладывает на него и встречное ограничение — минимальный размер фрагмента определяется в 1/8 логического блока. Другие же возможные значения — 1/4 и 1/2 блока файловой системы (очевидно, что выделение фрагмента в размере блока равносильно отказу от фрагментации блока вообще, хотя это, как будто бы, не запрещено).
Inodes
Каким образом определяется принадлежность блока данных тому или иному файлу? К помощью индексной таблицы, именуемой также таблицей индексных дескрипторов или таблицей inodes. Она образована некоторым (конечным) количеством записей фиксированной длины (128 байт в UFS, 256 — в UFS2), каждая из которых однозначно соответствует одному файлу, как реально существующему, так и только могущему быть созданным.
Такая запись индексной таблицы носит название inode, которое мы и оставим за нею. Ибо все известные мне переводы этого термина, вроде информационных узлов или индексных дескрипторов, выглядят очень коряво. Кроме того, слово «дескриптор» фигурирует еще и в контексте «дескриптор файла», под чем подразумевается идентификатор (уникальный, иначе что же он будет идентифицировать?) файла, используемого неким процессом (что уже к файловым системам не имеет ни малейшего отношения — это сфера подсистемы управления процессами). И эти дескрипторы — не имеют меж собой ничего общего. Так, inode c идентификатором 2 (а это всегда идентификатор корневого каталога файловой системы) и дескриптор файла с номером 2 (а им для любого процесса будет стандартное устройство вывода сообщений об ошибках, /dev/stderr ) ни коим образом друг с другом не соотносятся (хотя об этом почему-то не любят говорить вслух).
Однако я отвлекся — вернемся к нашим inodes. Каждый член этой таблицы содержит так называемые метаданные файла. Для реально существующего файла они включают в себя:
А вот чего в inode не обнаружить никакими силами — так это имени соответствующего ему (или ей? — мне почем-то кажется, что inode, вопреки грамматике, — женского рода). В любой книжке про Unix не устают повторять (и я не отступлю от этой доброй традиции), что имя файла — не атрибут самого файла, а элемент каталога, в который он входит. Поскольку понимание этого потребуется вскоре при знакомстве с механизмом Soft Updates, сделаю маленькое отступление для прояснения вопроса именования файлов во FreeBSD (и вообще в Unix).
При описании содержания таблицы inodes вскользь было упомянуто поле типа файла. Так вот, в Unix все файлы (а все, что в Unix имеется вообще, включая физические устройства, для системы представляется в виде файлов) делятся на две группы — каталоги и прочие. Прочие файлы могут служить для различных целей (хранения данных и исполняемых программ, быть символическими ссылками, описывать устройства или средства взаимодействия процессов). Назначение же каталогов — единственное, но оченно важное: быть хранителями имен входящих в них файлов, которым однозначно поставлены в соответствие идентификаторы inodes, хранящих метаданные этих файлов.
То есть имя файла существует только в списке каталога и нигде более в системе. А создание файла — это не только заполнение относящейся к нему записи в индексной таблице и заполнение указанных в ней блоков данных, но и внесение записи вида «идентификатор — имя_файла» в область данных какого-либо каталога. А каталог, как и любые другие файлы, имеет свои метаданные в таблице inodes и свою область данных. И, в свою очередь, имя его вместе с идентификатором inode входит в каталог более высокого уровня, и так — вплоть до корня файловой системы. В поле количества ссылок inode создаваемого файла устанавливается минимально возможное значение, равное единице, поскольку любой файл входит по меньшей мере в один каталог, иначе он просто не будет доступен системе — файлы с нулевым количеством ссылок для нее как бы не существуют (и на самом деле их inodes и блоки данных со временем неизбежно будут перезаписаны физически; если, конечно, файл не был открыт в какой-либо программе — в этом случае он будет сущестовать, даже если имя его удалено из всех каталогов).
Ссылки, с помощью которых связывается имя файла как элемент каталога с его записью в таблице inodes и блоками образующих файл данных, именуются еще жесткими (hardlinks, хорошим русскоязычным эквивалентом было бы слово «связь», но оно как-то не прижилось). Посредством жестких ссылок одному и тому же набору данных или исполняемой программе можно придать произвольное количество имен, которые никто не запрещает включить в один и тот же или разные каталоги. Единственное условие для этого — все эти имена-дублеры должны находиться в каталогах единой файловой системы (фигурально говоря, на одной дисковой партиции, хотя, как это будет показано в разделе о программном RAID’е, это не совсем точно).
Определенности ради отмечу, что жесткие ссылки нужно отличать от ссылок символических (symlinks, часто говорят просто links — почему и резонно было бы сохранит за ними обозначение ссылок, а hardlinks по русски именовать связями). Символические ссылки — файлы особого типа, отдаленно сходные с ярлыками в Windows или shadow в OS/2, которые сами по себе никаких данных не содержат, а просто описывают путь к имени другого файла (который может локализоваться и за пределами данной файловой системы).
Для файлов несуществующих свободные записи в таблице inodes просто резервируются. А поскольку количество этих записей — конечно, именно объем индексной таблицы и определяет, сколько файлов реально может быть создано в данной файловой системе. Исчерпание свободных записей в ней приводит к тому, что, вне зависимости от объема свободного дискового пространства, ни одного нового файла создать не удастся.
Блок группы цилиндров и суперблок
Таблицы inodes содержатся в блоке группы цилиндров, наряду с картами свободных/занятых inodes и карты свободных/занятых блоков данных). Это имеет целью размещение inodes и относящихся к ним блоков данных максимально близко друг к другу, что, кроме повышения производительности (за счет минимизации перемещений головок), влечет за собой и сведение к минимуму той самой внешней фрагментации данных, о которой говорилось выше.
Однако сведений об объеме индексной таблицы в блоке группы цилиндров не обнаруживается. Ибо место их размещения — тот самый суперблок, который идет первым в нашей партиции (вообще-то первым в любой партиции будет загрузочный блок, но реально он занят только в загрузочном же разделе — во всех остальных для него просто зарезервировано место). А также дублируется в каждой группе цилиндров — чем обеспечивается устойчивость к механическим повреждениям диска. Кроме этого, в суперблоке же записывается размер блока файловой системы и их суммарное количество, число блоков данных, размер блокового фрагмента и их число в блоке, число блоков, реально занятых файлами, объем партиции, перманентно резервируемый как свободный, и еще множество характеристик файловой системы, о которых сейчас говорить неуместно.
Практика форматирования
Команда newfs требует единственного аргумента — имени файла форматируемой партиции, например,
Тема Soft Updates, однако, столь интересна сама по себе, что заслуживает отдельного обсуждения, чем мы и займемся в следующем разделе. А пока под рассмотрим отличия текущей разновидности файловой системы FreeBSD, UFS2, от ее предшественницы — UFS.
Все, что было сказано выше о файловой системе FreeBSD, относилось в равной мере к обеим ее разновидностям. Главная особенность UFS2 — то, что она 64-разрядная и, соответственно, способна работать с дисковыми объемами более терабайта (интересно, скоро это станет актуальным для настольного пользователя? Судя по темпам дискобольства, срок этот не за горами). В этой связи напомню, что длина записи в таблице inodes в UFS2 удвоилась, и равна 256 байт.
Далее, в UFS2 включена поддержка расширенных атрибутов файлов, в частности, ACL, но это существенно для сетевых администраторов. А вот что может заметить пользователь — то, что создание новой файловой системы происходит быстрее (на больших дисковых разделах это действительно заметно, что называется, органолептически). Происходит это за счет т.н. «ленивой» инициализации inodes, хотя динамического их выделения, как, например, в XFS, и нету.
Парадокс Soft Updates
При всех своих многочисленных достоинствах, файловая система FreBSD не может похвастаться одним — быстродействием. И это не смотря на то, что в основе ее лежит обще-берклианская FFS — быстрая файловая система. Однако эпитет здесь выступает в сравнении с прежней Unix’овой файловой системой — s5, все вариации которой, как говорят знающие люди, отличались исключительной задумчивостью. Если же сравнить производительность файловой системы FreeBSD с родной для Linux Ext2fs — перед пользователем она предстанет существенно более медленной, чем последняя, особенно на операциях с большим количеством мелких файлов.
Почему? Нетрудно ответить: вследствие принятого во FreeBSD по умолчанию режима обращения с измененными файлами. Большинство нормальных файловых систем способны функционировать в одном из трех режимов:
Очевидно, что первый режим обеспечивает наибольшую устойчивость файловой системы к сбоям, второй — наибольшее быстродействие файловых операций (ценой возможности нарушения целостности файловой системы и даже полного ее разрушения при аварийном завершении работы), а третий представляет собой как бы компромисс между первым и вторым решением.
Так вот, в файловой системе Linux (конкретно — в ext2fs, Linux нынче за родные признает много файловых систем) по умолчанию задействуется полностью асинхронный режим работы, а во FreeBSD — смешанный. Конечно, это определяется при монтировании файловых систем, и с помощью соответствующих опций команды mount (что я покажу в соответствующей заметке) файловую систему FreeBSD можно заставить работать полностью асинхронно. Однако резонные люди не рекомендуют это делать категорически — и, вероятно, имеют к тому основания (одна из причин к тому станет ясной в конце этого раздела). Да и, как следует из тестов, существенного прироста быстродействия асинхронное монтрование файловых систем во FreeBSD не дает.
И действительно, в умолчальном режиме файловая система FreeBSD (в сравнении с той же ext2fs) демонстрирует замечательную устойчивость. За годы общения с этой ОС (а из которых половина пришлась на селянские условия, когда неожиданное отключение электричества было вещью более чем обычной) мне ни разу не пришлось столкнуться с проблемами из-за аварийного завершения сеанса работы (в Linux’е такие проблемы, до внедрения журналируемых файловых систем, возникали сплошь и рядом).
Однако цена за это — быстродействие. Вернее, отсутствие оного. И проявляется это особенно наглядно именно при копировании большого количества мелких файлов (процедура, весьма обычная при работе с текстовыми, по преимуществу, материалами). Действительно, при этом в синхронном режиме обновляется огромное количество файловых inodes, тогда как собственно данных изменяется ничтожное по объему количество, и их кэширование доставляет мало радости. В любом случае копирование набранных в текстовом редакторе статеюшечек размером с эту заметку и суммарным объемом в стандартный CD затягивается на вполне чувствительное время (в отличие от Linux’а, где подобная операция выполняется внешне мгновенно — другое дело, что индикатор активности жесткого диска может еще долго подмигивать).
Далее, не смотря на всю свою фактическую устойчивость, файловая система FreeBSD, не будучи журналируемой, сама по себе не имеет механизма гарантии собственной целостности. То есть: при аварийном завершении работы, когда в файловой системе не устанавливается т.н. бит чистого размонтирования (clean byte — это один из важных параметров файловой системы, записываемый в ее суперблоке при корректном выходе из системы), в ходе процедуры последующей загрузки принудительно вызывается программа проверки ее на предмет нахождения противоречий между метаданными и областями данных (и их устранения). А при современных объемах дисков (и, соответственно, файловых систем на них) такая проверка может затянуться на часы. Конечно, это особенно прискорбно для серверов, но и на настольной машине доставляет мало положительных эмоций.
Проблема нарушения целостности существует и в Linux’е (по указанным выше причинам — даже в большей мере). И в Linux’е с нею борются посредством журналирования, то есть опережающей регистрации изменений метаданных (и, в некоторых случаях, даже и данных). Во FreeBSD же борьба за целостность файловой системы велась исторически по двум направлениям. Одно из них (хотя исторически и второе) — появившаяся в 5-й ветке фоновая проверка целостности файловой системы, допускающая начало нормальной работы сразу после аварийной перезагрузки машины. Поскольку это — одно из принципиальных новшество, скажу пару слов по сему поводу.
Для проверки целостности файловой системы во FreeBSD используется утилита fsck (одноименная есть и в Linux — для ext2fs, есть аналогичные инструменты и для прочих файловых систем). Она может быть запущена пользователем (вернее, root’ом) из командной строки. Однако схема старта системы предусматривает ее принудительный запуск, если в какой-либо из автоматически монтируемых файловых систем не обнаружен бит чистого размонтирования. А поскольку fsck — побитная операция, во избежание тяжких последствий она обычно проводится на размонтированных файловых системах.
Так было и во FreeBSD вплоть до версий 4-й ветки. А вот в версиях 5-й ветки, начиная с первой, проверка диска может выполняться на смонтированной и готовой к работе файловой системе. И, соответственно, в фоновом режиме после полной загрузки системы, параллельно с выполнением обычной работы. Казалось бы — пустячок, а приятно: затрудняюсь сказать, сколько заняла бы полная проверка обычных ныне 80- или 120-гигабайтных винтов.
Однако первым по времени реализации способом борьбы за целостность файловой системы был механизм Soft Updates, обеспечивающий одновременно (вернее, главным образом) и повышение быстродействия файловых операций.
Сам по себе механизм Soft Updates описан далее. В двух же словах суть этого механизма — в сведении к минимуму синхронных операций записи без явно асинхронного манипулирования метаданными, с одной стороны, но и без предварительного журналирования метаданных (как в файловых системах типа ReiserFS или XFS) — с другой.
Реализуется это, опять же говоря довольно грубо (детали реализации моему пониманию недоступны — каюсь) за счет так называемых зависимостей обновления. Что такое эти зависимости — интуитивно ясно из примера создания нового (для простоты — пустого) файла. Для этого требуется:
С точки зрения целостности файловой системы, эти операции должны быть выполнены именно в этой последовательности. То есть наличие в каталоге имени файла с идентификатором незаполненного (еще не созданного или уже уничтоженного) inode — явный непорядок: именно для исправления такого рода безобразий и запускается программа проверки диска после аварийного завершения сеанса.
Выполнять связанные зависимостями операции обновления в синхронном режиме — долго (каждая потребует своего обращения к диску), в асинхронном — нет гарантии сохранения последовательности (обновления в кэше могут быть записаны тогда, когда бог на душу положит). Так вот, механизм Soft Updates обеспечивает, с одной стороны, контроль за последовательностью выполнения зависимых обновлений (что способствует целостности состояния файловой системы), с другой — группирует их в единую атомарную операцию синхронного обращения к диску, за счет сокращения числа коих и растет производительность. В этом, насколько я понимаю, и состоит объяснение парадокса Soft Updates — неожиданного увеличения и надежности, и быстродействия.
В общем, постарался объяснить, как смог и как сам понял — за подробностями к упомянутой статье. В дополнение только замечу — во избежание недоразумений: механизм Soft Updates не только не гарантирует сохранности пользовательских данных, не записанных на диск по раздолбайству юзера перед крахом системы, но и не преследует такой цели. Его призвание — следить, чтобы файловая система всегда представала по возможности в непротиворечивом виде. Впрочем, то же можно сказать и о любой журналируемой файловой системе — ни одна из них не страхует от ошибок пользователя…
Теперь посмотрим, как же Soft Updates можно использовать. Если создавать файловые системы через sysinstall — все просто: там по умолчанию включение этого механизма уже давно (версии примерно с 4.3) предусмотрено для всех файловых систем, кроме корневой. Последнее аргументируется соображениями безопасности. Да и для корневой файловой системы Soft Updates не особо нужна: при правильном разбиении диска и грамотной эксплуатации запись в нее (после первичной установки) происходит только при инсталляции нового ядра, а часто ли это проделывается в нормальных условиях?
Размонтировать все файловые системы, кроме корневой (с ней все равно этот номер не пройдет) командой
для каждого раздела, в файловой системе которого требуется Soft Updates. И, наконец, повторением команды
вернуться в многопользовательский режим. Перезагрузки, что характерно, не потребуется.
В принципе, Soft Updates можно включить и для корневой файловой системы, но для этого потребуется загрузка с внешнего носителя, типа rescue-CD из штатного комплекта FreeBSD.
Да, забыл сказать, что механизм Soft Updates требует включения соответствующей опции в конфигурацию ядра. Впрочем, по умолчанию в ядре GENERIC это уже сделано — важно только не отключить ее случайно при пересборке.
Что же дает Soft Updates с точки зрения производительности? Как оказалось, очень немало. В упоминавшейся выше статье приведены результаты выполнения файловых операций в обычном синхронном режиме, в режиме чисто асинхронном (при котором игнорируются все зависимости обновлений), и в синхронном режиме с Soft Updates. Результаты этих тестов показывают, что быстродействие операций записи и удаления файлов с включением Soft Updates возрастает в 2 и 20 раз соответственно, лишь на 5% уступая результатам чисто асинхронного режима. Из чего следует резонность совета резонных людей — не включать асинхронный режим: использование его просто не обеспечивает прироста производительности, оправдывающего снижение надежности.
Я в свое время (еще на FreeBSD 4-й ветки) провел серию сравнений быстродействия файловых операций в UFS (как без Soft Updates, так и с ней) и в файловых системах Linux (ext2fs, ext3fs, reiserfs). Использовался массив в 4 Гбайт очень смешанного характера, от большого количества мелких html’ок до нескольких объемных tiff- и avi-файлов, то есть типичный набор данных настольного пользователя.
Результаты впечатляли. Если UFS в чистом виде проигрывала по скорости ext2fs в 4-6 раз на копировании и более чем в 10 — на удалении файлов, то при задействованном Soft Updates разница в скорости копирования не превышала полутора раз, а скорость удаления практически сравнялась (в пределах ошибки эксперимента). Обе же журналируемые же файловые системы Linux не обнаружили отличий в быстродействии от UFS с Soft Updates — а ведь только их можно сравнивать между собой с точки зрения формальной устойчивости…
Подчеркну, что файловые системы FreeBSD во всех случаях монтировались в соответствие с рекомендациями, то есть в «смешанном» режиме, тогда все файловые системы Linux’а — в режиме всинхронном, как это принято в этой ОС. Так что не столь уж медленна UFS, как это обычно считается…