☰

UUID диска из вывода blkid исчезает

tag-icon • tag-icon linux mount uuid device-mapper block-device
UUID диска из вывода blkid исчезает

У меня странная ситуация на RHEL-7. Я создаю устройство отображения (crypt) на разделе диска, а затем копирую данные (байты) из раздела диска в mapper. Вывод blkid содержит две записи для UUID — одну для раздела диска и другую для mapper. UUID в /dev/disk/by-uuid указывает на mapper, поскольку он был перезаписан.

вывод blkid:

/dev/sdc1: UUID="1e762c4a-0b12-40fc-9f53-a825016211a0" TYPE="ext4"

/dev/mapper/my_mapper: UUID="1e762c4a-0b12-40fc-9f53-a825016211a0" TYPE="ext4"

Вывод /dev/disk/by-uuid:

lrwxrwxrwx 1 root root 10 Jan 31 10:24 1e762c4a-0b12-40fc-9f53-a825016211a0 -> ../../dm-4

Теперь я снова копирую данные (байты) из mapper в раздел диска и закрываю mapper. UUID в /dev/disk/by-uuid указывает на раздел диска, а вывод blkid показывает UUID для раздела диска.

вывод blkid:

/dev/sdc1: UUID="1e762c4a-0b12-40fc-9f53-a825016211a0" TYPE="ext4"

Вывод /dev/disk/by-uuid:

lrwxrwxrwx 1 root root 10 Jan 31 10:24 1e762c4a-0b12-40fc-9f53-a825016211a0 -> ../../sdc1

но как только я пытаюсь смонтировать раздел диска, я получаю ошибку:

mount -t ext4 -o rw /dev/sdc1 /mnt/plainDisk
mount: wrong fs type, bad option, bad superblock on /dev/sdc1.

и затем диск исчезает из вывода blkid. /dev/disk/by-uuid все еще присутствует с правильным UUID и lsblk показывает диск.

Я использую его blockdev --getsize64для получения размера диска в байтах, а затем копирую все эти байты.

Любые вклады или указания приветствуются. Хотя я не сталкиваюсь с этой проблемой на RHEL-6.

Дополнительная информация:

  1. Я использую fsyncфайловый дескриптор /dev/sdc1 после копирования всех данных.
  2. Я проверил вывод dumpe2fs, когда /dev/sdc1 присутствовал после второго копирования. Он совпал с исходными значениями. Однако после удаления записи dumpe2fs выдает ошибку:

dumpe2fs 1.42.9 (28 декабря 2013 г.)

dumpe2fs: Неправильное магическое число в суперблоке при попытке открыть /dev/sdc1

Не удалось найти допустимый суперблок файловой системы.

решение1

Проблема была в том, что при копировании данных обратно из my_mapperв sdc1, my_mapperвсе еще былосмонтированный. Это как-то повлияло на суперблок на устройстве. Я запустил dumpe2fsи проверил, что есть некоторые записи, связанные сустанавливатьв суперблоке.

Отключение картографа перед копированием данных решило проблему.

Связанный контент