Парадокс Soft Updates

Парадокс Soft Updates
   При всех своих многочисленных достоинствах, файловая система FreBSD не
   может похвастаться одним -- быстродействием. И это не смотря на то,
   что в основе ее лежит обще-берклианская FFS -- быстрая файловая
   система. Однако эпитет здесь выступает в сравнении с прежней Unix'овой
   файловой системой -- s5, все вариации которой, как говорят знающие
   люди, отличались исключительной задумчивостью. Если же сравнить
   производительность файловой системы FreeBSD с родной для Linux Ext2fs
   -- оно окажется не в пользу первой, особенно на операциях с большим
   количеством мелких файлов.

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

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

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

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

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

   Далее, не смотря на всю свою фактическую устойчивость, файловая
   система FreeBSD, не будучи журналируемой, сама по себе не имеет
   механизма гарантии собственной целостности. То есть: при аварийном
   завершении работы, когда в файловой системе не устанавливается т.н.
   бит чистого размонтирования (clean byte -- это один из важных
   параметров файловой системы, записываемый в ее суперблоке при
   корректном выходе из системы), в ходе процедуры последующей загрузки
   принудительно вызывается программа проверки ее на предмет нахождения
   противоречий между метаданными и областями данных (и их устранения). А
   при современных объемах дисков (и, соответственно, файловых систем на
   них) такая проверка может затянуться на часы. Конечно, это особенно
   прискорбно для серверов, но и на настольной машине доставляет мало
   положительных эмоций.

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

   Для проверки целостности файловой системы во FreeBSD используется
   утилита fsck (одноименная есть и в Linux -- для ext2fs, есть
   аналогичные инструменты и для прочих файловых систем). Она может быть
   запущена пользователем (вернее, root'ом) из командной строки. Однако
   схема старта системы предусматривает ее автоматический запуск, если в
   какой-либо из автоматически монтируемых файловых систем не обнаружен
   бит чистого размонтирования. А поскольку fsck -- побитная операция, во
   избежание тяжких последствий она обычно проводится на размонтированных
   файловых системах. Что и было во FreeBSD вплоть до версии, как
   минимум, 4.6 (более старших из 4-й ветки уже не видел). А вот в
   версиях 5-й ветки, начиная с первой, более чем годичной давности,
   developer'ской, проверка диска может выполняться на смонтированной и
   готовой к работе файловой системе. И, соответственно, в фоновом режиме
   после полной загрузки системы, параллельно с выполнением обычной
   работы. Казалось бы -- пустячок, а приятно: затрудняюсь сказать,
   сколько заняла бы полная проверка обычных ныне 80- или 120-гигабайтных
   винтов.

   Однако первым по времени реализации способом борьбы за целостность
   файловой системы был механизм Soft Updates, обеспечивающий
   одновременно (вернее, главным образом) и повышение быстродействия
   файловых операций.

   Сам по себе механизм Soft Updates (оставим этот термин без перевода --
   варианты оного типа <<мягких обновлений>> не только не блещут
   литературным изяществом, но и сути дела не проясняют) детально описан
   в специальной статье Макказика и Ганджера, смысла пересказывать
   которую я не вижу (благо она имеется в [30]русском переводе). В двух
   же словах суть этого механизма -- в сведении к минимуму синхронных
   операций записи без явно асинхронного манипулирования метаданными, с
   одной стороны, но и без предварительного журналирования метаданных
   (как в файловых системах типа ReiserFS или XFS) -- с другой.

   Реализуется это, опять же говоря довольно грубо (детали реализации
   моему пониманию недоступны -- каюсь) за счет так называемых
   зависимостей обновления. Что такое эти зависимости -- интуитивно ясно
   из примера создания нового (для простоты -- пустого) файла. Для этого
   требуется:
     * запись в таблице inodes, с заполнением полей типа файла, его
       идентификатора, счетчика ссылок (со значением 1 -- каждый файл
       должен принадлежать как минимум одному каталогу), ну и прочих там
       -- прав доступа в соответствие с их маской, и так далее;
     * изменение карты свободных/занятых inodes в блоке группы цилиндров
       (соответствующий новому файлу inode должен быть помечен в ней
       битом занятости);
     * внесение записи вида <<идентификатор -- имя_файла>> в структуру
       каталога, в котором новый файл создается, что обеспечивает ту
       самую единственную ссылку в соответствующем поле inode файла.

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

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

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

   Теперь посмотрим, как же Soft Updates можно использовать. Если
   создавать файловые системы через sysinstall -- все просто: там по
   умолчанию включение этого механизма уже давно (версии примерно с 4.3)
   предусмотрено для всех файловых систем, кроме корневой. Последнее
   аргументируется соображениями безопасности, которые (для настольной
   машины) не кажутся мне убедительными -- так что я включаю ее и здесь.
   Хотя именно для корневой файловой системы Soft Updates не особо нужна:
   при правильном разбиении диска и грамотной эксплуатации запись в нее
   (после первичной установки) происходит только при инсталляции нового
   ядра, а часто ли это проделывается в нормальных условиях?

   При создании же файловых систем вручную, командой newfs, Soft Updates
   автоматически не включается: это нужно сделать, как уже говорилось,
   указанием опции:

        $ newfs -U /dev/ad#s#?

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

        $ shutdown now

   Размонтировать все файловые системы, кроме корневой (с ней все равно
   этот номер не пройдет) командой

        $ umount -Af

   Дать команду

        tunefs -n enable /dev/ad#s#?

   для каждого раздела, в файловой системе которого требуется Soft
   Updates. И, наконец, повторением команды

        $ shutdown now

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

   В принципе, 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 -- а ведь только их можно сравнивать между собой с точки
   зрения формальной устойчивости...

    Алексей Федорчук (alv@linux-online.ru, UNIX4all - http://linuxshop.ru/unix4all)
    Опубликовано -- 15 февраля 2004 г.