Вопрос или проблема
Я читал о контрольных суммах ext4 (https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums), но не уверен, что именно они проверяют. Название подразумевает, что охватываются только метаданные, а не фактические данные в файлах? Какие ошибки могут быть обнаружены?
Я не вижу реальной пользы в проверке контрольной суммы самих данных файла. Это дорогостоящая операция на блок данных неизвестного размера и дублирует усилия, которые выполняются самим диском.
Контрольные суммы здесь обеспечивают проверку целостности на уровне файловой системы, фактические данные на диске будут полагаться на внутренние контрольные суммы самого диска. Проверяя контрольные суммы метаданных, вы защищаете критически важные структуры файловой системы от ошибок программного обеспечения и обеспечиваете дополнительный уровень защиты.
По сути, если данные повреждены в файловой системе, контрольная сумма данных подскажет, от чего можно отказаться или что нужно проверить и перепроверить. Преимущества (и потенциальные накладные расходы) проверки контрольных сумм больших файлов минимальны, когда это уже делается самим диском.
Также процедура проверки контрольных сумм файла может легко выполняться приложением, которое изначально записывало данные; архивные форматы делают это, и многие приложения проверяют целостность данных, чтобы быть уверенными, что они не загружают мусор. Выполнение этого на уровне файловой системы, а также приложения и диска было бы избыточным и почти наверняка ненужным.
Автор патча резюмировал, что охватывается здесь:
Суперблок хранит crc32c самого себя.
Каждый inode хранит crc32c(fs_uuid + inode_num + inode_gen + inode + slack_space_after_inode)
Блок и битовые карты каждого инода получают свои собственные crc32c(fs_uuid + group_num + bitmap), хранящиеся в дескрипторе блока группы.
Каждый блок дерева extents хранит crc32c(fs_uuid + inode_num + inode_gen + extent_entries) в неиспользуемом пространстве в конце блока.
Каждый блок листа директории имеет выглядящую неиспользуемой запись директории, достаточно большую для хранения crc32c(fs_uuid + inode_num + inode_gen + block) в конце блока.
Каждый блок дерева htree директории укорочен для хранения crc32c(fs_uuid + inode_num + inode_gen + block) в конце блока.
Блоки расширенных атрибутов хранят crc32c(fs_uuid + id + ea_block) в заголовке, где id в зависимости от счетчика ссылок может быть inode_num и inode_gen; или номером блока.
Блоки MMP хранят crc32c(fs_uuid + mmpblock) в конце блока MMP.
Группы блоков теперь могут использовать crc32c вместо crc16.
Журнал теперь имеет флаг функции контрольной суммы v2.
crc32c(j_uuid + block) контрольные суммы были вставлены в блоки описателя, блоки фиксации, блоки отзыва и суперблок журнала.
Каждая метка блока в блоке описателя имеет контрольную сумму соответствующего блока данных.
Ответ или решение
EXT4 является одним из самых популярных файловых систем, которые используются в Linux, и обеспечивает высокую надежность и производительность хранения данных. Одним из ключевых аспектов надежности EXT4 является использование контрольных сумм метаданных (ext4 metadata checksums) для защиты целостности файловой системы. В связи с этим часто возникает вопрос: на какие именно данные распространяются эти контрольные суммы и какие ошибки они могут выявить?
### Что покрывают метаданные контрольных сумм в EXT4?
Метаданные контрольных сумм в EXT4 предназначены для проверки целостности критических структур файловой системы, не охватывая при этом сами данные в файлах. Фокус на метаданных позволяет обнаруживать и устранять ошибки, возникающие в результате программных багов или повреждений данных. Это дополнительно защищает файловую систему и увеличивает её устойчивость к сбоям.
#### 1. Суперблок:
– Содержит CRC32C контрольную сумму самого себя. Это ключевая структура, отражающая конфигурацию и текущее состояние файловой системы.
#### 2. Иноды:
– Каждый инод содержит CRC32C контрольную сумму, вычисляемую на основе уникальных идентификаторов файловой системы (fs_uuid), номера инода (inode_num), поколения инода (inode_gen), и непосредственно инода плюс пространства после него.
#### 3. Битмапы блоков и инодов:
– Каждая карта битов получает собственную CRC32C контрольную сумму, которая хранится в описателе группы блоков и вычисляется на основе fs_uuid, номера группы и самой карты битов.
#### 4. Блоки дерева экстентов:
– Содержат CRC32C, включающую fs_uuid, номер инода, поколение инода и записи экстента.
#### 5. Листовые блоки директорий и htree-блоки:
– Похожим образом, эти блоки содержат CRC32C, рассчитанную на основе уникальных идентификаторов и адресных данных блока.
#### 6. Блоки расширенных атрибутов:
– Хранят CRC32C в заголовке блока, с использованием идентификаторов, зависящих от количества ссылок на объект.
#### 7. MMP-блоки и группы блоков:
– Используют CRC32C вместо более старого стандарта CRC16, значительно увеличивая точность проверки.
#### 8. Журнал:
– Включает в себя v2 feature флаг контрольной суммы. CRC32C контрольные суммы вставлены в базисные блоки, блоки фиксации, блоки отмены и суперблок журнала.
### Преимущества и выявление ошибок
Проверка целостности метаданных позволяет выявить ошибки, такие как неверное использование ресурсов файловой системы, сбои из-за программных ошибок или ошибки, вызванные аппаратным обеспечением. Это делает систему более надежной и способной к быстрому восстановлению после сбоя.
### Заключение
Контрольные суммы метаданных в EXT4 предоставляют дополнительный уровень защиты и важны для поддержания общей целостности файловой системы. Хотя контроль файловых данных может показаться избыточным на уровне файловой системы из-за аппаратных и прикладных средств защиты, контроль метаданных играет критически важную роль в устойчивости файловой системы к повреждениям.