Как проверить наличие плохих блоков на физическом томе LVM?

Когда вы используете ext4, вы можете проверить наличие бадблоков с помощью команды e2fsck -c /dev/sda1 # or whatever. Это приведет к «черному списку» блоков, добавив их в индекс плохих блоков.

Что эквивалентно этому для физического тома LVM2? Файловая система на нем - ext4, но, вероятно, обнаруженные поврежденные блоки станут недействительными, поскольку базовая установка LVM перемещает данные на физическом диске.

Другими словами, как я могу проверить, не повреждены ли блоки в LVM?

Когда вы используете ext4, вы можете проверять наличие бадблоков с помощью команды e2fsck -c /dev/sda1или чего-либо еще. Это приведет к «черному списку» блоков, добавив их в индекс плохих блоков.

e2fsck -cработает badblocksна базовом жестком диске. Вы можете использовать badblocksкоманду непосредственно на физическом томе LVM (при условии, что PV на самом деле является жестким диском, а не каким-либо другим виртуальным устройством, например, программным RAID-устройством MD), так же, как вы использовали бы эту команду на жестком диске. который содержит файловую систему ext.

Это не добавит никакой плохой информации о блоках в файловую систему, но я не думаю, что это полезная функция файловой системы; жесткий диск должен обрабатывать плохие блоки.

Даже лучше, чем badblocksсамотестирование SMART на диске (замените /dev/sdXна имя устройства вашего жесткого диска):

smartctl -t long /dev/sdX
smartctl -a /dev/sdX | less

Сам тест займет несколько часов (он точно скажет, как долго). Когда это будет сделано, вы можете запросить результат с помощью smartctl -aпоиска самопроверки. Если написано «Успешно завершено», с вашим жестким диском все в порядке.

Другими словами, как я могу проверить, не повреждены ли блоки в LVM?

Как я уже сказал, сам жесткий диск гарантирует, что он не использует поврежденные блоки, и он также будет перемещать данные из этих блоков; это не то, что должна делать файловая система или LV. С другой стороны, когда на вашем жестком диске больше, чем несколько плохих блоков, вам не нужно что-то, что перемещает их, но вы хотите заменить весь жесткий диск, потому что он выходит из строя.

Я уверен, что LVM не обрабатывает плохие блоки; он ожидает, что основное хранилище И большинство, если не все, современные жесткие диски. Вам может потребоваться выполнить запись в сектор, но диск должен переназначить его. (Вам может понадобиться сначала выполнить автономное сканирование поверхности, например, с помощью smartctl /dev/sda -t offline).

Тем не менее, LVM на самом деле не перемещает данные, если вы не спросите их, например, с pvmove. Таким образом, вы можете использовать функцию ext4 badblocks; вам просто придется перепроверить на наличие плохих блоков, если запустить pvmove. Нет обычной операции (например, lvextend) перемещения данных.

Расширение не перемещает данные, потому что LVM сохраняет карту, говоря, что «логические экстенты 0–99 - это физические экстенты 200–299», а затем, когда вы расширяете их, он просто добавляет «логические экстенты 100–199 - это физические экстенты 100–199». Или даже «логические экстенты 100–149 - это физические экстенты 50–99; логические экстенты 150–199 - это физические экстенты 140–189». LVM не заботится о том, что физические экстенты не в порядке или не являются смежными.

pvckможет проверять метаданные LVM, после этого согласованность является задачей файловой системы. LVM касается только управления томами, поэтому ему не нужно заботиться о том, является ли пространство, составляющее определенный экстент, плохим, поскольку программное обеспечение более высокого уровня улавливает эти проблемы. В любом случае метаданные LVM занимают только первый (необязательно также последний сектор) физического тома.

Если только первый и последний секторы достаточно большого PV (такого, как вы могли бы видеть в производстве) случайно потерпели неудачу одновременно, у вас, по сути, самая маленькая удача в мире, так как это астрономически маловероятно. В противном случае, если администратор знает, что происходит сбой в нескольких секторах диска, большинство людей в порядке, просто регистрируя такие вещи под заголовком «Жесткий диск вышел из строя навсегда и требует замены».

Если pvckвозвращается ошибка, вы можете проверить, где хранятся ваши резервные копии метаданных LVM /etc/lvm. Если это так, вы можете pvcreateуказать резервную копию для--restorefile

Синтаксис:

pvcreate --uuid "<UUID-of-target-PV>" --restorefile <Path-To-Metadata-Backup-File> <path-to-PV-block-device>

Пример:

pvcreate --uuid "2VydVW-TNiN-fz9Y-ElRu-D6ie-tXLp-GrwvHz" --restorefile /etc/lvm/archive/vg_raid_00000-1085667159.vg /dev/sda2 

Если восстановление не работает (например, если первый сектор плохой), вы можете повторить описанное выше, но установить --metadatacopies 2(или вы можете просто сделать это прямо), который попытается записать метаданные в первый и Последние сектора на PV. Когда это pvscanпроисходит при загрузке, он проверит оба места и, если найдет метаданные, проверит их по контрольной сумме. Если контрольная сумма не удалась в первом секторе, но успешно в последнем секторе, вы получите нефатальное сообщение об ошибке.

Вид ручного управления и боль, но опять же, это одна из причин, почему люди взволнованы, чтобы получить избыточность управления громкостью с BTRFS. Большую часть времени это не такая уж большая проблема по упомянутым Дероберту причинам, а потому, что люди, которым абсолютно необходимо обеспечить непрерывность данных, обычно используют RAID и имеют стратегию резервного копирования.