LinuxShare

Оригинал: 30 days with JFS
Автор: Keith Winston
Дата: 14 сентября 2007
Перевод: Александр Тарасов aka oioki
Дата перевода: 1 октября 2007
При копировании материала обязательны указание автора, переводчика и ссылки на оригинал статьи и настоящую страницу как первоисточник перевода!

JFS (Journaled File System) - малоизвестная файловая система, исходный код которой открыт IBM в 1999 и включен в исходный код ядра Linux начиная с 2002 года. JFS родилась внутри IBM как стандартная файловая система для линейки AIX Unix-серверов. Позже была портирована на OS/2. Несмотря на хорошую родословную, JFS не приобрела повсеместной популярности, в отличие от ext2/3 и ReiserFS. Чтобы узнать больше о JFS, я установил ее в качестве корневой файловой системы. Обнаружилось, что JFS - достойная альтернатива более известным файловым системам.

Чтобы попробовать JFS, я установил Slackware 12 на мой ноутбук и выбрал JFS в качестве основной файловой системы. Я не выполнял каких-либо особых разбиений, а просто создал один большой раздел для всего. При установке не произошло ничего достойного внимания, и система нормально загрузилась посредством GRUB. Не все дистрибутивы предлагают JFS в качестве файловой системы, и некоторые не имеют поддержки JFS в предлагаемых скомпилированных ядрах. Пользователи Fedora Core и SUSE имеют возможность использовать JFS, но по умолчанию ставится ext3. На дистрибутивах Slackware, Debian, Ubuntu и их производных также можно попробовать JFS.

Первое, что бросилось в глаза - отсутствие каталога lost+found - пережитка других файловых систем.

JFS - полностью 64-битная файловая система. При обычном блоке размером 4 Кб возможно создание файловой системы до 4 Петабайт (размер будет меньше, если выбрать меньшие размеры блоков). Наименьшая поддерживаемая система - 16 Мб. Журнал транзакций JFS по умолчанию имеет размер в 0.4% от общего размера, округленный до мегабайт. Максимальный размер журнала - 32 Мб. Интересная особенность разметки диска - выделенное рабочее место для fsck, небольшая область расположенная внутри файловой системы, предназначенная для учета распределения блоков при загрузке (если для учета большой файловой системы на этом этапе недостаточно памяти).

JFS динамически выделяет место для дисковых inode, освобождая место, когда оно больше не требуется. Это устраняет возможность нехватки inode из-за большого числа мелких файлов. На данный момент JFS - единственная файловая система в ядре, которая поддерживает эту функцию. Из соображений производительности и эффективности содержимое мелких каталогов хранится в inode самого каталога. Внутри inode может храниться до 8 записей, включая записи для текущего (.) и родительского (..) каталогов. Большие каталоги для быстрого чтения используют B+-деревья с ключом по имени. JFS использует экстенты для выделения блоков файлам, что благоприятно сказывается на использовании места на диске при увеличении размеров файлов. Эта функция также доступна в XFS, и является нововведением в ext4.

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

В дополнение к стандартным правам, JFS поддерживает немного более расширенные атрибуты, такие как "неизменный" (i, immutable) и "лишь для присоединения" (append-only, a). Эти атрибуты просматриваются и устанавливаются с помощью программ lsattr и chattr. Мне не удалось найти полноценной информации по поддержке JFS списков прав доступа (Access Control List, ACL).

Журналирование

Основной целью разработки JFS было создание системы быстрого восстановления после падений файловой системы больших размеров, без долгих проверок на ошибки (fsck). Это также было и целью создания файловых систем ext3 и ReiserFS. Но в отличие от ext3, в JFS способность журналирования не является каким-то расширением, а встроена в структуру изначально. Для высокопроизводительных приложений, журнал транзакций JFS может быть создан на внешнем разделе - нужно лишь указать это при создании файловой системы.

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

Вот список операций файловой системы, которые заносятся в журнал JFS:

• Создание файла (create)
• Создание ссылки на файл (link)
• Создание каталога (mkdir)
• Создание узла (node) (mknod)
• Удаление файла (unlink)
• Переименование (rename)
• Удаление каталога (rmdir)
• Создание символической ссылки (symlink)
• Усечение обычного файла

Утилиты

JFS предоставляет набор утилит для управления файловой системой. Для их использования нужно использовать учетную запись root.

Программа	Описание
jfs_debugfs	Редактор файловой системы JFS в виде оболочки. Позволяет изменять ACL, uid/gid, режимы, временные метки и т.п. Возможно также изменять данные на диске, но только путем ввода шестнадцатеричных строк - не самый эффективный способ редактирования файла.
jfs_fsck	Пересматривает журнал транзакций JFS, проверяет и исправляет ошибки. Можно запускать программу лишь на отмонтированных файловых системах или доступных лишь для чтения. Запускается автоматически при загрузке системы.
jfs_fscklog	Извлекает служебный журнал fsck JFS в файл. jfs_fscklog -e /dev/hda6 извлекает бинарный журнал в файл fscklog.new. Для просмотра используйте jfs_fscklog -d fscklog.new.
jfs_logdump	Сохраняет журнал в текстовый файл. В итоговом файле будут указаны данные каждой транзакции.
jfs_mkfs	Создает раздел, форматированный в JFS. Для создания внешнего журнала используйте ключ -j устройство (работает начиная с версии 1.0.18).
jfs_tune	Настраивает параметры файловой системы JFS. Однако я не нашел параметры, которые могли бы ощутимо увеличить производительность. Ключ -l выводит информацию о суперблоке.

Дамп суперблока выглядит примерно так:

root@slackt41:~# jfs_tune -l /dev/hda6
jfs_tune version 1.1.11, 05-Jun-2006

JFS filesystem superblock:

JFS magic number:       'JFS1'
JFS version:            1
JFS state:              mounted
JFS flags:              JFS_LINUX  JFS_COMMIT  JFS_GROUPCOMMIT  JFS_INLINELOG 
Aggregate block size:   4096 bytes
Aggregate size:         12239720 blocks
Physical block size:    512 bytes
Allocation group size:  16384 aggregate blocks
Log device number:      0x306
Filesystem creation:    Wed Jul 11 01:52:42 2007
Volume label:           ''

Испытание на устойчивость

Белая бумага и man-страницы не идут ни в какое сравнение с жесткими условиями серверной. Для проверки способности к восстановлению у JFS, я начал ронять систему (принудительное выключение компьютера) при высокой нагрузке. Я повторял каждое испытание дважды, чтобы убедиться в достоверности результатов.

Нагрузка во время испытания	Восстановление
Консоль (без X), в ней запущен текстовый редактор с открытым файлом	Около 2 секунд на пересмотр журнала. Несохраненные изменения потеряны, но файл оказался в порядке.
X window с запущенными KDE, GIMP, Nvu и текстовым редактором в окне xterm, все с открытыми файлами	Около 2 секунд на пересмотр журнала. Все открытые файлы в порядке, несохраненные изменения пропали.
X window с запущенными KDE, GIMP, Nvu и текстовым редактором, все с открытыми файлами. В добавок запущен скрипт, вставляющий записи в таблицу MySQL (ISAM). Скрипт представляет собой бесконечный цикл, перед падением системы он работал несколько минут, чтобы записи успели записаться на диск.	Около 3 секунд на пересмотр журнала. Все открытые файлы в порядке, база данных осталась целостной, несколько тысяч записей вставлено, но временная метка файла таблицы откатилась на 1 минуту.

Во всех случаях при загрузке системы появлялось сообщение:

**Phase 0 - Replay Journal Log
-|----- (индикатор показался на несколько секунд, затем исчез)
Filesystem is clean

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

Заключение

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

После 30 дней избиений я полностью уверен в JFS, теперь я могу доверять свои данные JFS. JFS может быть не столь известна, как другие файловые системы, но это хороший выбор в большом списке файловых систем для Linux.