Die Datenträger-UUID der blkid-Ausgabe wird ausgeblendet

563
user2255299

Ich habe eine merkwürdige Situation bei RHEL-7. Ich erstelle einen Device-Mapper (Crypt) über einer Festplattenpartition und kopiere dann Daten (Bytes) von der Festplattenpartition in den Mapper. Die Ausgabe von blkid enthält zwei Einträge für die UUID - einen für die Festplattenpartition und den anderen für den Mapper. Die UUID unter / dev / disk / by-uuid zeigt beim Überschreiben auf den Mapper.

blkid-Ausgabe:

/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-Ausgabe:

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

Nun kopiere ich wieder Daten (Bytes) von Mapper in die Festplattenpartition und schließe den Mapper. Die UUID unter / dev / disk / by-uuid zeigt auf die Festplattenpartition, und die Ausgabe von blkid zeigt die UUID für die Festplattenpartition an.

blkid-Ausgabe:

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

/ dev / disk / by-uuid-Ausgabe:

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

Sobald ich jedoch versuche, die Festplattenpartition einzuhängen, erhalte ich die Fehlermeldung:

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

und dann verschwindet die Festplatte aus der blkid-Ausgabe. Das Verzeichnis / dev / disk / by-uuid ist immer noch mit der richtigen UUID vorhanden, und lsblk zeigt die Platte an.

Ich verwende blockdev --getsize64, um die Größe der Festplatte in Bytes abzurufen und dann alle diese Bytes zu kopieren.

Alle Eingaben oder Zeiger werden geschätzt. Ich habe jedoch keine Probleme mit RHEL-6.

Zusätzliche Information:

  1. Ich verwende fsyncden / dev / sdc1-Dateideskriptor, wenn alle Daten kopiert sind.
  2. Ich habe die dumpe2fs-Ausgabe überprüft, wenn / dev / sdc1 nach der zweiten Kopie vorhanden war. Es stimmte mit den ursprünglichen Werten überein. Nachdem der Eintrag jedoch entfernt wurde, gibt dumpe2fs den Fehler aus:

dumpe2fs 1.42.9 (28.12.2013)

dumpe2fs: Ungültige magische Zahl im Superblock beim Versuch, / dev / sdc1 zu öffnen

Gültiger Dateisystem-Superblock konnte nicht gefunden werden.

0
Was sagt dmesg? Attie vor 6 Jahren 0
In dmesg gab es keinen Fehler außer "falscher Fs-Typ". user2255299 vor 6 Jahren 0
`VFS: Ext4-Dateisystem kann nicht gefunden werden` user2255299 vor 6 Jahren 0

1 Antwort auf die Frage

1
user2255299

Das Problem war, dass während des Kopieren von Daten zurück aus my_mapperzu sdc1, my_mapperwurde noch montiert . Dies hatte irgendwie Auswirkungen auf den Superblock auf dem Gerät. Ich lief dumpe2fsund überprüfte, ob es einige Einträge gibt, die sich auf das Einhängen in den Superblock beziehen .

Durch das Aufheben der Bereitstellung des Mapper vor dem Kopieren der Daten wurde das Problem behoben.

Verwandte Probleme