Война миров: ext2 vs ext3

Крис Касперски ака мыщъх

Хакер, номер #086, стр. 086-108-1

Взгляд на файловые системы Linux под необычным углом

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

[введение]

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

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

[когда данные обращаются в прах]

Файловые системы ext2 и ext3 очень похожи. ext3 - это ext2 с поддержкой журналирования, то есть транзакцией. Транзакциями называют групповые операции, выполняемые или невыполняемые как одна единая операция. Другими словами, атомарно. Поясним это на классическом примере перевода денег из банка А в банк Б. На низком уровне эта операция разбивается на две: снятие денег со счета и перевод. А если во время перевода произойдет сбой, и выполнение программы прервется? Чтобы не оставить клиента без денег, необходимо предусмотреть автоматический «откат». Перевод либо выполняется, либо нет. Промежуточные состояния недопустимы.

Вернемся к файловым системам. Почему в FAT16/32 постоянно образуются потерянные кластеры? Да потому, что она не поддерживает транзакций, и многостадийные операции выполняются не атомарно! Вот, например, копирование файла. Система выделила дисковое пространство и только собиралась передать его файлу, как все повисло (варианты: монтер перерезал провода, юзер нажал на RESET), и один или несколько кластеров остались ничейными.

Журналируемые файловые системы (ext3, NTFS) в таких случаях делают автоматический «откат» при следующей загрузке, и потери кластеров не происходит. Создание/удаление/переименование файла - это атомарные операции, которые не могут допустить промежуточных состояний. А вот с операциями перемещения все намного сложнее. Файловая система не позволяет перемещать файл между томами, вынуждая программу-оболочку делать это самостоятельно. В результате операция переноса разбивается на две: копирование файла-источника в файл-приемник и удаление источника. При этом может возникнуть такая нехорошая ситуация, когда файл-приемник не был записан на диск (система не успела сбросить кэш, например), но источник уже был удален. Вот такие они транзакции. К тому же поддержка транзакций не может застраховать от потери записываемых данных, поскольку файл журнала обновляется не мгновенно, а с некоторой задержкой. Транзакции бессильны противостоять физическим дефектам поверхности, некорректно работающему программному обеспечению и т.д.

Содержание  Вперед на стр. 086-108-2
ttfb: 3.7038326263428 ms