ext3 , или третья расширенная файловая система , — это журналируемая файловая система , которая обычно используется с ядром Linux . Раньше она была файловой системой по умолчанию для многих популярных дистрибутивов Linux , но в целом была вытеснена своей последующей версией ext4 . [3] Главным преимуществом ext3 перед ее предшественником ext2 является журналирование , которое повышает надежность и устраняет необходимость проверки файловой системы после неправильного, то есть нечистого, выключения.
Стивен Твиди впервые сообщил, что он работает над расширением ext2 в Journaling the Linux ext2fs Filesystem в статье 1998 года, а затем в сообщении в списке рассылки ядра в феврале 1999 года. Файловая система была объединена с основным ядром Linux в ноябре 2001 года, начиная с версии 2.4.15. [4] [5] [6]
Скоростные характеристики ext3 менее привлекательны, чем у конкурирующих файловых систем Linux, таких как ext4, JFS , ReiserFS и XFS , но ext3 имеет существенное преимущество в том, что она позволяет производить обновления с ext2 на месте без необходимости резервного копирования и восстановления данных. Тесты показывают, что ext3 также использует меньше ресурсов ЦП, чем ReiserFS и XFS. [7] [8] Она также считается более безопасной, чем другие файловые системы Linux, из-за своей относительной простоты и более широкой базы тестирования. [9] [10]
ext3 добавляет следующие функции к ext2:
Без этих функций любая файловая система ext3 также является допустимой файловой системой ext2. Такая ситуация позволила использовать хорошо протестированные и зрелые утилиты обслуживания файловых систем для обслуживания и восстановления файловых систем ext2 также с ext3 без серьезных изменений. Файловые системы ext2 и ext3 используют один и тот же стандартный набор утилит, e2fsprogs , который включает инструмент fsck . Тесная связь также делает преобразование между двумя файловыми системами (как вперед в ext3, так и назад в ext2) простым.
ext3 не хватает "современных" функций файловой системы, таких как динамическое распределение inode и экстенты . Такая ситуация иногда может быть недостатком, но для восстанавливаемости это существенное преимущество. Все метаданные файловой системы находятся в фиксированных, хорошо известных местах, а структуры данных имеют некоторую избыточность. При значительном повреждении данных ext2 или ext3 могут быть восстановлены, тогда как файловая система на основе дерева — нет.
Максимальное количество блоков для ext3 — 2 32. Размер блока может варьироваться, влияя на максимальное количество файлов и максимальный размер файловой системы: [12]
В реализации ext3 для Linux доступны три уровня журналирования :
Во всех трех режимах внутренняя структура файловой системы гарантированно останется согласованной даже после сбоя. В любом случае, будут затронуты только данные содержимого файлов или каталогов, которые были изменены при сбое системы; остальное останется нетронутым после восстановления.
Поскольку ext3 стремится быть обратно совместимой с более ранней ext2, многие из структур на диске похожи на ext2. Следовательно, ext3 не имеет последних функций, таких как экстенты , динамическое распределение inodes и блочное подраспределение. [15] Каталог может иметь не более 31998 подкаталогов , поскольку inode может иметь не более 32000 ссылок (каждый прямой подкаталог увеличивает счетчик ссылок inode родительской папки в ссылке ".."). [16]
На ext3, как и для большинства современных файловых систем Linux, системный инструмент " fsck " не следует использовать, пока файловая система смонтирована для записи. [3] Попытка проверить файловую систему, которая уже смонтирована в режиме чтения/записи, (весьма вероятно) обнаружит несоответствия в метаданных файловой системы. Когда метаданные файловой системы изменяются, а fsck применяет изменения в попытке привести "несогласованные" метаданные в "согласованное" состояние, попытка "исправить" несоответствия повредит файловую систему.
Не существует онлайн- инструмента дефрагментации ext3 , который работает на уровне файловой системы. Есть офлайн-дефрагментатор ext2, e2defrag. Однако e2defragможет уничтожить данные в зависимости от включенных в файловой системе битов функций; он не знает, как обрабатывать многие из новых функций ext3. [17]
Существуют инструменты дефрагментации пользовательского пространства, такие как Shake [18] и defrag. [19] [20] Shake работает, выделяя место для всего файла как одну операцию, что обычно заставляет распределитель находить непрерывное дисковое пространство. Если есть файлы, которые используются одновременно, Shake попытается записать их рядом друг с другом. Defrag работает, копируя каждый файл на себя. Однако эта стратегия работает только в том случае, если в файловой системе достаточно свободного места. Настоящего инструмента дефрагментации для ext3 не существует. [21]
Однако, как утверждается в руководстве системного администратора Linux, «Современные файловые системы Linux сводят фрагментацию к минимуму, размещая все блоки в файле близко друг к другу, даже если они не могут быть сохранены в последовательных секторах. Некоторые файловые системы, такие как ext3, эффективно выделяют свободный блок, который находится ближе всего к другим блокам в файле. Поэтому нет необходимости беспокоиться о фрагментации в системе Linux». [22]
Хотя ext3 устойчива к фрагментации файлов, ext3 может фрагментироваться со временем или при определенных шаблонах использования, например, при медленной записи больших файлов. [23] [24] Следовательно, ext4 (преемница ext3) имеет онлайн-утилиту дефрагментации файловой системы e4defrag [25] и в настоящее время поддерживает экстенты (непрерывные области файлов).
ext3 не поддерживает восстановление удаленных файлов. Драйвер ext3 активно удаляет файлы, стирая иноды файлов [26] в целях безопасности при сбоях.
Существует несколько методов [27] и некоторое бесплатное [28] и проприетарное [29] программное обеспечение для восстановления удаленных или утерянных файлов с использованием анализа журнала файловой системы; однако они не гарантируют какого-либо конкретного восстановления файла.
e3compr [30] — неофициальный патч для ext3, который делает прозрачное сжатие . Это прямой порт e2compr, который все еще нуждается в дальнейшей разработке. Он хорошо компилируется и загружается с ядрами upstream [ требуется ссылка ] , но журналирование пока не реализовано.
В отличие от ряда современных файловых систем, ext3 не имеет встроенной поддержки снимков , возможности быстро фиксировать состояние файловой системы в произвольные моменты времени. Вместо этого она полагается на менее эффективные по пространству снимки на уровне тома, предоставляемые Linux LVM . Файловая система Next3 — это модифицированная версия ext3, которая предлагает поддержку снимков, но при этом сохраняет совместимость с форматом ext3 на диске. [31]
ext3 не выполняет контрольную сумму при записи в журнал. На устройстве хранения с дополнительным кэшем, если barrier=1 не включен как опция монтирования (в /etc/fstab ), и если оборудование выполняет кэширование записи вне очереди, возникает риск серьезного повреждения файловой системы во время сбоя. [32] [33] [34] Это происходит потому, что устройства хранения с кэшем записи сообщают системе, что данные были полностью записаны, даже если они были записаны в (изменчивый) кэш.
Если запись на жесткий диск выполняется не по порядку (из-за того, что современные жесткие диски кэшируют записи для амортизации скорости записи), то, скорее всего, будет записан блок фиксации транзакции до того, как будут записаны другие соответствующие блоки. Если сбой питания или неустранимый сбой произойдет до того, как будут записаны другие блоки, систему придется перезагрузить. После перезагрузки файловая система воспроизведет журнал как обычно и воспроизведет «победителей» (транзакции с блоком фиксации, включая недействительную транзакцию выше, которая случайно была помечена допустимым блоком фиксации). Таким образом, незавершенная запись на диск выше будет продолжена, но с использованием поврежденных данных журнала. Таким образом, файловая система ошибочно перезапишет нормальные данные поврежденными данными при воспроизведении журнала. Если бы использовались контрольные суммы, где блоки транзакции «поддельного победителя» были бы помечены взаимной контрольной суммой, файловая система могла бы знать лучше и не воспроизводить поврежденные данные на диск. Контрольная сумма журнала была добавлена в ext4. [35]
Файловые системы, проходящие через интерфейс сопоставления устройств (включая программные реализации RAID и LVM), могут не поддерживать барьеры и выдавать предупреждение, если используется эта опция монтирования. [36] [37] Также существуют некоторые диски, которые не реализуют должным образом расширение очистки кэша записи, необходимое для работы барьеров, что приводит к аналогичному предупреждению. [38] В таких ситуациях, когда барьеры не поддерживаются или нецелесообразны, надежный порядок записи возможен путем отключения кэша записи диска и использования data=journalопции монтирования. [32] Отключение кэша записи диска может потребоваться даже при наличии барьеров.
Такие приложения, как базы данных, ожидают вызова fsync() для сброса ожидающих записей на диск, а реализация барьера не всегда очищает кэш записи диска в ответ на этот вызов. [39] Также существует потенциальная проблема с реализацией барьера, связанная с обработкой ошибок во время событий, таких как сбой диска. [40] Также известно, что иногда некоторые технологии виртуализации неправильно пересылают команды fsync или flush на базовые устройства (файлы, тома, диск) из гостевой операционной системы. [41] Аналогично, некоторые жесткие диски или контроллеры неправильно реализуют очистку кэша или не реализуют ее вообще, но все равно заявляют, что она поддерживается, и не возвращают никаких ошибок при ее использовании. [42] Существует так много способов неправильной обработки fsync и обработки кэша записи, что безопаснее предположить, что очистка кэша не работает, если она не протестирована явно, независимо от того, насколько надежными считаются отдельные компоненты.
Ext3 хранит даты как время Unix , используя четыре байта в заголовке файла. 32 бита не дают достаточного объема для продолжения обработки файлов после 18 января 2038 года — проблема 2038 года . [43]
28 июня 2006 года Теодор Цо , главный разработчик ext3, [44] анонсировал улучшенную версию, названную ext4. 11 октября 2008 года исправления, которые отмечают ext4 как стабильный код, были объединены в репозитории исходного кода Linux 2.6.28, что ознаменовало окончание фазы разработки и рекомендовало его принятие. В 2008 году Цо заявил, что хотя ext4 имеет улучшенные функции, такие как гораздо более высокая скорость, чем ext3, это не является крупным шагом вперед, она использует старую технологию и является временной мерой; Цо считает, что Btrfs — лучшее направление, потому что «она предлагает улучшения в масштабируемости, надежности и простоте управления». [45] Btrfs также имеет «ряд тех же идей дизайна, что и reiser3 / 4 ». [46]
{{cite journal}}: Цитировать журнал требует |journal=( помощь )Файловая система Ubuntu по умолчанию ("ext3") будет фрагментировать большие (>1 ГБ), медленно растущие файлы (<1 МБ/с)
Мы обнаружили сильно фрагментированные свободные области на интенсивно используемом сервере IMAP, который хранит все свои письма в отдельных файлах – хотя более 900 ГБ из общего дискового пространства в 1,4 ТБ все еще были доступны