Linux: Полное руководство

Во-первых, одному индексному дескриптору может соответствовать любое количество имен, приписанных к разным каталогам, и все они являются настоящими. Количество имен (жестких ссылок) учитывается в индексном дескрипторе. Именно это количество вы можете увидеть по команде ls -l.

Во-вторых, удаление файла означает просто удаление записи о нем из данных каталога и уменьшение на 1 счетчика ссылок.

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

Сам каталог таким же образом приписан к своему родительскому каталогу. Корневой каталог всегда записан в индексный дескриптор с номером 2 (номер 1 отведен для списка адресов дефектных блоков). В каждом каталоге хранится ссылка на него самого и на его родительский каталог — это и есть псевдоподкаталоги «.» и «..».

Таким образом, количество ссылок на каталог равно количеству его подкаталогов плюс два.

Данные каталога представляют собой связный список с записями переменной длины и выглядят примерно так, как на рис. 2.2.

Рис. 2.2. Строение каталога в ext2fs

А как же файлы физических устройств? Они могут находиться в тех же каталогах, что и обычные файлы: в каталоге нет никаких данных, говорящих о принадлежности имени файлу на диске или устройству. Разница находится на уровне индексного дескриптора. Если i-узел обычного файла указывает на дисковые блоки, где хранятся его данные, то в i-узле файла устройства содержится указатель на список драйверов устройств в ядре — тот элемент списка, который соответствует старшему номеру устройства (рис. 2.3).

Рис. 2.3. Разница между обычным файлом и файлом устройства

Свойства файловой системы ext2fs:

♦ Максимальный размер файловой системы — 4 Тбайт.

♦ Максимальный размер файла — 2 Гбайт.

♦ Максимальная длина имени файла — 255 символов.

♦ Минимальный размер блока — 1024 байт.

♦ Количество выделяемых индексных дескрипторов — 1 на 4096 байт раздела.

2.2.2. Журналируемые файловые системы

Представим такую ситуацию. У вас есть жесткий диск, скажем, на 80 Гб. Сегодня таким объемом никого не удивишь, не так ли? Вы поленились разбить его на разделы, и у вас есть один большой раздел, занимающий все ваши 80 Гб. И вот в момент записи на диск произошло отключение питания. Хорошо, если это случилось во время записи данных какого-то файла, пусть и очень важного: файл можно восстановить хотя бы частично. А вот если свет погас, когда операционная система записывала метаданные, то расположение файла на диске перестанет соответствовать списку принадлежащих ему блоков в индексном дескрипторе. Файловая система может утратить целостность, то есть такое состояние, когда каждый блок принадлежит не более чем одному файлу (inode). В результате вы можете не досчитаться не одного, а сотни файлов.

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

Если при монтировании файловой системы в процессе загрузки операционная система обнаруживает, что чистый бит не установлен, она запускает средство проверки файловой системы — программу fsck. Представляете, сколько времени займет такая проверка? Даже при условии, что ошибок будет мало или вообще не будет, придется ждать довольно долго. А если еще будет нарушена целостность, тогда восстановление этой целостности займет еще несколько минут вашего времени.

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

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

Журналировать операции записи самих данных тоже можно: в этом случае есть вероятность, что данные после сбоя будут восстановлены. Правда, согласно золотому правилу механики, за все нужно платить, и платить приходится быстродействием.

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

И все же лучшим средством от неожиданного отключения до сих пор являются источники бесперебойного питания…

Современные версии ядра Linux (2.6.x) поддерживают в качестве родных четыре журналируемые файловые системы: ReiserFS, ext3fs, XFS и JFS. Из них журналирование данных поддерживает только ext3fs. Список файловых систем, которые поддерживаются вашим ядром, содержится в файле /proc/filesystems.

ReiserFS

Разработана Хансом Райзером (Hans Reiser) и его компанией Namesys (http://www.namesys.com) и официально включена в ядро 2.4.4. Преимущества данной ФС в основном проявляются в работе с мелкими файлами: они целиком хранятся в своих i-узлах (inode), без выделения блоков в области данных. Вместе с экономией места это способствует и росту производительности, так как данные и метаданные хранятся в непосредственной близости и могут быть считаны одной операцией ввода/вывода.

Другая особенность ReiserFS состоит в том, что хвосты файлов длиной меньше чем в один блок могут быть упакованы в один дисковый блок (режим тайлинга). Это обеспечивает около 5% экономии дискового пространства. Именно работа с маленькими файлами (меньше килобайта) и обслуживание большого их количества выделяет данную ФС среди прочих.

ReiserFS несовместима с ext2fs на уровне утилит обслуживания файловой системы, однако соответствующий инструментарий, объединенный в пакет reiserfsprogs, уже давно включается в стандартную поставку современных дистрибутивов. Если у вас его нет, то скачать можно по адресу ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.19.tar.gz.

Там же можно взять патчи для ядра 2.4.x.

К сожалению, загрузчики Linux (LILO и GRUB) не способны загрузить ядро Linux с раздела ReiserFS, оптимизированного в режиме тайлинга. Поэтому под каталог /boot лучше отводить отдельный раздел с файловой системой, совместимой с ext2fs.

XFS

При работе с огромными (терабайтными) файлами вне конкуренции остается файловая система XFS, разработанная компанией Silicon Graphics (сейчас SGI) специально для операций с мультимедийными данными и впервые появившаяся в 1994 г. в версии ОС Irix 5.3. Она использует 64-битную адресацию, что позволяет увеличить максимальный размер файловой системы до 18 тысяч петабайт (при этом предельный размер файла составляет 9 тысяч петабайт).