
Estoy experimentando una situación extraña en RHEL-7. Creo un asignador de dispositivos (cripta) sobre una partición de disco y luego copio datos (bytes) de la partición del disco al asignador. La salida blkid tiene dos entradas para el UUID: una para la partición del disco y otra para el asignador. El UUID en /dev/disk/by-uuid apunta al asignador ya que fue sobrescrito.
salida negra:
/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 salida:
lrwxrwxrwx 1 root root 10 Jan 31 10:24 1e762c4a-0b12-40fc-9f53-a825016211a0 -> ../../dm-4
Ahora, vuelvo a copiar datos (bytes) del asignador a la partición del disco y cierro el asignador. El UUID en /dev/disk/by-uuid apunta a la partición del disco y la salida blkid muestra el UUID de la partición del disco.
salida negra:
/dev/sdc1: UUID="1e762c4a-0b12-40fc-9f53-a825016211a0" TYPE="ext4"
/dev/disk/by-uuid salida:
lrwxrwxrwx 1 root root 10 Jan 31 10:24 1e762c4a-0b12-40fc-9f53-a825016211a0 -> ../../sdc1
pero, una vez que intento montar la partición del disco, aparece el error:
mount -t ext4 -o rw /dev/sdc1 /mnt/plainDisk
mount: wrong fs type, bad option, bad superblock on /dev/sdc1.
y luego el disco desaparece de la salida blkid. El /dev/disk/by-uuid todavía está presente con el UUID correcto y lsblk muestra el disco.
Estoy usando blockdev --getsize64
para obtener el tamaño del disco en bytes y luego copiando todos estos bytes.
Se agradece cualquier aportación o sugerencia. Sin embargo, no me enfrento a este problema en RHEL-6.
Información adicional:
- Utilizo
fsync
el descriptor de archivo over /dev/sdc1 una vez que se copian todos los datos. - Verifiqué la salida de dumpe2fs cuando /dev/sdc1 estaba presente después de la segunda copia. Coincidía con los valores originales. Sin embargo, una vez que se eliminó la entrada, dumpe2fs muestra el error:
dumpe2fs 1.42.9 (28 de diciembre de 2013)
dumpe2fs: Número mágico incorrecto en el superbloque al intentar abrir /dev/sdc1
No se pudo encontrar un superbloque válido del sistema de archivos.
Respuesta1
El problema era que mientras se copiaban los datos de my_mapper
a sdc1
, my_mapper
todavía eramontado. Esto de alguna manera afectó al superbloque del dispositivo. Corrí dumpe2fs
y verifiqué que hay algunas entradas relacionadas conmontaren la supermanzana.
Desmontar el asignador antes de copiar los datos resolvió el problema.