Вопросы Теги

Может ли файловая система ext4 противостоять плохому сектору (нечитаемому)?

Попробуйте чистый bash

#!/bin/bash
TEST_STRING="{0,1}, alpha, {(x,y,z)}, {{1,2,3}, {a,b,c}}"
TEST_STRING="$TEST_STRING"","
count=0
newword=''
while [ "${TEST_STRING::1}" ] ; do 
    l="${TEST_STRING::1}"
    TEST_STRING=${TEST_STRING:1}
    [ "$l" = '{' ] && ((count++))
    [ "$l" = '}' ] && ((count--))
    if [ "$l" = ',' ] && ! ((count)) ; then
        echo "Word='$newword'"
        newword=''
    else
        if [ "$newword" ] || [ "$l" != " " ] ; then
            newword="$newword""$l"
        fi
    fi
done
5
09.02.2019, 11:21
1 ответ

После некоторого исследования вопроса "если ext4может обрабатывать ошибку чтения с блочных устройств" мой предварительный вывод:в ext4 существует лишь частичная избыточность

Вот некоторые результаты моего «анализа» ext4«функций безопасности» (, основанные на Ext4 wiki и «Структура инода в файловой системе EXT4»)

  • с несколькими исключениями, такими как встроенные данные или встроенные данныеext4хранят содержимое файла «блоки данных» и «метаблоки -данных» файловой системы отдельно. Насколько я понимаю, ext4принимает только меры для некоторого ремонта/резервирования в отношении последних.
  • восстановление/избыточность метаданных зависит от )недавно введенной/добавленной функции контрольной суммы и b )наличия дополнительных копий важных метаданных -
  • такие "важные метаданные -данные " (в том смысле, что они находятся в разных частях блочного устройства ).
    1. суперблок ext4
    2. информация block group descriptors.
  • контрольные суммы защищают суперблок, множественное -монтирование -защиту, расширенные атрибуты, записи каталогов, узлы HTREE, экстенты, индексные дескрипторы и групповые дескрипторы. В то время как экстенты (защищены новой ext4функцией, которая частично заменяет старую непрямую адресацию блоков (IBA )), старые блоки IBA не защищены, как указано :

    Notice that there is neither a magic number nor a checksum to provide any level of confidence that the [IBA] block isn't full of garbage.

Что ext4 может восстановить на нечитаемом секторе диска (512/4K)

  • Потеря суперблоков и дескрипторов групп блоков , избыточные копии которых хранятся либо во всех/или в некоторых конкретных группах блоков на диске.
  • Потеря записи каталога,из-за нечитаемого сектора не происходит потери доступа и тем более содержимого файлов, хранящихся в каталоге (теряются только их имена ). Файлы (, включая подкаталоги ), остаются доступными через ихfilespec<inode-number>в debuge2fs.
  • Потеря частей inode table. Каждая запись в таблице инодов (, таблица разделена и части записываются в группы блоков, которые формируют ext4структуру диска ), занимает (дополненные )256 байт. Следовательно, нечитаемый сектор должен означать потерю только от 2 до 16 файлов. Кроме того, благодаря функциям контрольной суммы любые повреждения в таблице индексных дескрипторов должны быть, если не обязательно, исправимыми, но не остаться незамеченными.

Что такое проблемы, вызванные плохим сектором ext4, кажется, не защищает от

  • Некритичные метаданные, включая индексные дескрипторы, записи каталогов, экстенты, IBA не защищены.
  • inodes:Как уже упоминалось, индексный дескриптор, занимающий 256 байт и являющийся основным дескриптором блоков, составляющих данные файла, означает потерю доступа к 2–16 файлам (, в основном независимо от их размера ).
  • записи каталога :, если они потеряны из-за поврежденного сектора, означают, что в путях файлов -ко всем файлам внутри будет потеряна часть имени файла. Размер сбойного сектора 512 или 4 КБ, с одной стороны, а также имена файлов и пространство, занимаемое функцией хеширования каталогов, влияют на степень потери. Кроме того, насколько я понимаю, хеширование каталогов по существу обеспечивает избыточность (, но я не могу этого гарантировать ).
  • экстенты :потеряли части информации в деревьях экстентов, так же как и потеря самого индексного дескриптора поставит под угрозу доступ к блокам данных, составляющим содержимое файла, и, следовательно, будет означать примерно потерю 1 файла.
  • Блоки IBA:(см. экстенты )+, как упоминалось ранее, будут дополнительно подвержены повышенной уязвимости также к частичному повреждению (, что, однако, не было основным вопросом ).

дополнительно использовались методы

чтобы проверить и доказать некоторые из перечисленных проблем с ext4структурой диска (в отношении его устойчивости к поврежденным секторам )следующие инструменты удобны

  • debugfs <blockdev>который позволяет получить доступ к файлам через спецификацию файлов (либо путь к файлу, либо в случае проблем через номер инода в< >)
  • truncate, dd, losetup, mountи mkfs.ext4для создания ext4файловых систем для игры.
  • dumpe2fs, tune2fs, которые предоставляют информацию
  • dm-setupсобрать виртуальное блочное устройство, имитирующее ошибку чтения, подобную этой :
    $> dmsetup create badsectordevice << EOF
0 2902 linear /dev/loop1 0
2902 2 error
2904 17576 linear /dev/loop1 2904
EOF
    , где, как показано в примере, сектор блочного устройства равен 512, а ext4размер блока равен 1024, следовательно, и, следовательно, сектора LBA 2902, 2903 не читаются.
5
27.01.2020, 20:41

Теги

Похожие вопросы