Ich erlebe eine seltsame Situation unter RHEL-7. Ich erstelle einen Geräte-Mapper (Crypt) über einer Festplattenpartition und kopiere dann Daten (Bytes) von der Festplattenpartition zum Mapper. Die blkid-Ausgabe hat zwei Einträge für die UUID – einen für die Festplattenpartition und einen für den Mapper. Die UUID unter /dev/disk/by-uuid verweist auf den Mapper, da sie überschrieben wurde.
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
Jetzt kopiere ich wieder Daten (Bytes) vom Mapper zur Festplattenpartition und schließe den Mapper. Die UUID unter /dev/disk/by-uuid zeigt auf die Festplattenpartition und die blkid-Ausgabe zeigt die UUID für die Festplattenpartition.
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
aber wenn ich versuche, die Festplattenpartition zu mounten, erhalte ich folgende 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. /dev/disk/by-uuid ist immer noch mit der korrekten UUID vorhanden und lsblk zeigt die Festplatte an.
Ich verwende es, blockdev --getsize64um die Festplattengröße in Bytes zu ermitteln und dann alle diese Bytes zu kopieren.
Ich bin für alle Eingaben und Hinweise dankbar. Bei RHEL-6 tritt dieses Problem bei mir jedoch nicht auf.
Zusätzliche Information:
- Ich verwende
fsyncden Dateideskriptor /dev/sdc1, sobald alle Daten kopiert sind. - Ich habe die Ausgabe von dumpe2fs überprüft, als /dev/sdc1 nach dem zweiten Kopieren vorhanden war. Sie stimmte mit den ursprünglichen Werten überein. Nachdem der Eintrag jedoch entfernt wurde, gibt dumpe2fs den folgenden Fehler aus:
dumpe2fs 1.42.9 (28. Dezember 2013)
dumpe2fs: Ungültige magische Zahl im Superblock beim Versuch, /dev/sdc1 zu öffnen
Es konnte kein gültiger Dateisystem-Superblock gefunden werden.
Antwort1
Das Problem war, dass beim Zurückkopieren der Daten von my_mappernach sdc1immer my_mappernochmontiert. Dies hat irgendwie den Superblock auf dem Gerät beeinflusst. Ich habe es ausgeführt dumpe2fsund überprüft, ob es einige Einträge gibt, die sich aufmontierenim Superblock.
Das Problem wurde behoben, indem der Mapper vor dem Kopieren der Daten ausgehängt wurde.