GPT + MBR Layout in SF Raid1 möglich?

[fulltilt]

bei mir wurde heute eine defekte NVME ausgetauscht, dabei wurde leider die neue NVME mit GPT Layout versehen (die originale läuft unter MBR). Das ganze ist mir erst später aufgefallen, syncing und boot ist alles fehlerfrei durchgelaufen:

Code: Alles auswählen

# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid1 nvme1n1p1[0] nvme0n1p1[2]
      33520640 blocks super 1.2 [2/2] [UU]
      
md1 : active raid1 nvme1n1p2[0] nvme0n1p2[2]
      523264 blocks super 1.2 [2/2] [UU]
      
md2 : active raid1 nvme1n1p3[0] nvme0n1p3[2]
      965991744 blocks super 1.2 [2/2] [UU]
      bitmap: 7/8 pages [28KB], 65536KB chunk

allerdings zeigt nvme list den Namespace Usage unterschiedlich an:

Code: Alles auswählen

Node             SN                   Model                                    Namespace Usage                      Format           FW Rev  
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1     S3xxxxxxxxxx2       SAMSUNG xxxx               1           1.02  TB /   1.02  TB    512   B +  0 B   EXA7301Q
/dev/nvme1n1     S3xxxxxxxxxx1       SAMSUNG xxxx               1         321.76  GB /   1.02  TB    512   B +  0 B   EXA7301Q

und gdisk -l

Code: Alles auswählen

Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. 

Es funktioniert jedoch alles problemlos ... die Techniker vom Datacenter sagen es könnte allenfalls leichte Performance Einbussen geben aber sofort alles noch einmal neu aufzusetzen wäre nicht zwingend erforderlich.
Was haltet ihr davon, ist ein Softraid mit GPT/ MBR möglich ohne dass Probleme auftreten?

[bluestar]

Den RAID-Partitionen dürfte das so ziemlich egal sein, ob deren Sektorenangaben aus ner klassischen Partitionstabelle oder ner GPT kommen.

Ob du Performanceverluste hast oder nicht, nun das liegt am Partitions-Alignment - dazu müsstest du die Partitionstabellen posten.

[fulltilt]

Den RAID-Partitionen dürfte das so ziemlich egal sein, ob deren Sektorenangaben aus ner klassischen Partitionstabelle oder ner GPT kommen.

Ob du Performanceverluste hast oder nicht, nun das liegt am Partitions-Alignment - dazu müsstest du die Partitionstabellen posten.

Danke, solange es sich nicht auf die Redundanz bei einem Drive Ausfall auswirkt, habe ich kein Problem damit.
Eine Wiederherstellung müsste dann nur entsprechend an das jeweilige Layout angelegt werden.

die Tabellen müssten korrekt sein:

Code: Alles auswählen

# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
nvme0n1     259:0    0 953.9G  0 disk  
├─nvme0n1p1 259:1    0    32G  0 part  
│ └─md0       9:0    0    32G  0 raid1 [SWAP]
├─nvme0n1p2 259:2    0   512M  0 part  
│ └─md1       9:1    0   511M  0 raid1 /boot
└─nvme0n1p3 259:3    0 921.4G  0 part  
  └─md2       9:2    0 921.2G  0 raid1 /
nvme1n1     259:4    0 953.9G  0 disk  
├─nvme1n1p1 259:5    0    32G  0 part  
│ └─md0       9:0    0    32G  0 raid1 [SWAP]
├─nvme1n1p2 259:6    0   512M  0 part  
│ └─md1       9:1    0   511M  0 raid1 /boot
└─nvme1n1p3 259:7    0 921.4G  0 part

[bluestar]

die Tabellen müssten korrekt sein:

Code: Alles auswählen

# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
nvme0n1     259:0    0 953.9G  0 disk  
├─nvme0n1p1 259:1    0    32G  0 part  
│ └─md0       9:0    0    32G  0 raid1 [SWAP]
├─nvme0n1p2 259:2    0   512M  0 part  
│ └─md1       9:1    0   511M  0 raid1 /boot
└─nvme0n1p3 259:3    0 921.4G  0 part  
  └─md2       9:2    0 921.2G  0 raid1 /
nvme1n1     259:4    0 953.9G  0 disk  
├─nvme1n1p1 259:5    0    32G  0 part  
│ └─md0       9:0    0    32G  0 raid1 [SWAP]
├─nvme1n1p2 259:6    0   512M  0 part  
│ └─md1       9:1    0   511M  0 raid1 /boot
└─nvme1n1p3 259:7    0 921.4G  0 part

Das sagt nichts über die Alignments

[fulltilt]

Das sagt nichts über die Alignments

output von fdisk -l -u /dev/xxx ?

[fulltilt]

hierbei werden keine Warnungen oder Fehler angezeigt ...
passt das so?

Code: Alles auswählen

# fdisk -l -u /dev/nvme0n1
Disk /dev/nvme0n1: 953.9 GiB, 1024209543168 bytes, 2000409264 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4ff164f4

Device         Boot    Start        End    Sectors   Size Id Type
/dev/nvme0n1p1          2048   67110911   67108864    32G fd Linux raid autodetect
/dev/nvme0n1p2      67110912   68159487    1048576   512M fd Linux raid autodetect
/dev/nvme0n1p3      68159488 2000407215 1932247728 921.4G fd Linux raid autodetect


# fdisk -l -u /dev/nvme1n1
Disk /dev/nvme1n1: 953.9 GiB, 1024209543168 bytes, 2000409264 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4ff164f4

Device         Boot    Start        End    Sectors   Size Id Type
/dev/nvme1n1p1          2048   67110911   67108864    32G fd Linux raid autodetect
/dev/nvme1n1p2      67110912   68159487    1048576   512M fd Linux raid autodetect
/dev/nvme1n1p3      68159488 2000407215 1932247728 921.4G fd Linux raid autodetect

## edit ##

Code: Alles auswählen

# sfdisk -d /dev/nvme0n1
label: dos
label-id: 0x4ff164f4
device: /dev/nvme0n1
unit: sectors
/dev/nvme0n1p1 : start=        2048, size=    67108864, type=fd
/dev/nvme0n1p2 : start=    67110912, size=     1048576, type=fd
/dev/nvme0n1p3 : start=    68159488, size=  1932247728, type=fd

# sfdisk -d /dev/nvme1n1
label: dos
label-id: 0x4ff164f4
device: /dev/nvme1n1
unit: sectors
/dev/nvme1n1p1 : start=        2048, size=    67108864, type=fd
/dev/nvme1n1p2 : start=    67110912, size=     1048576, type=fd
/dev/nvme1n1p3 : start=    68159488, size=  1932247728, type=fd

[bluestar]

Du hast ein Problem:

Code: Alles auswählen

# fdisk -l -u /dev/nvme0n1
Disklabel type: dos

und

Code: Alles auswählen

# fdisk -l -u /dev/nvme1n1
Disk /dev/nvme1n1: 953.9 GiB, 1024209543168 bytes, 2000409264 sectors
Disklabel type: dos

Zeigen das du auf beiden SSD eine klassische Partitionstabelle disklabel type: dos hast und offensichtlich liegt auf einer der beiden SSDs noch eine kaputte GPT:

und gdisk -l

Code: Alles auswählen

Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. 

Du solltest zusehen, dass du die kaputte GPT schleunigst los wirst, bevor du Daten verlierst.

[fulltilt]

Danke, ich habe nochmal explizit beim tech. Support nachgefragt:

Ursache für die Meldung trotz MBR Partitionen können "alte" Reste eine GPT-Partition sein, diese Meldung sollte sich allerdings nicht negativ auf den Betrieb auswirken.

wenn ich mit parted das Alignment überprüfe wird kein Fehler oder Warung ausgegeben ...

Code: Alles auswählen

# sudo parted /dev/nvme0n1 align-check opt 1
1 aligned
# sudo parted /dev/nvme0n1 align-check opt 2
2 aligned
# sudo parted /dev/nvme0n1 align-check opt 3
3 aligned
# sudo parted /dev/nvme1n1 align-check opt 1
1 aligned
# sudo parted /dev/nvme1n1 align-check opt 2
2 aligned
# sudo parted /dev/nvme1n1 align-check opt 3
3 aligned

gdisk -l xxx
converting MBR to GPT format in memory
sollte dies dann nicht erklären warum disklabel type: dos bei beiden angezeigt wird?

Code: Alles auswählen

# blkid
/dev/md0         5e39df1e-05f0-46b7-a56f-12134352bff4   swap       
/dev/md1         6264deeb-cea5-4537-bfcd-9a1fefcfa157   ext3       
/dev/md2         1a0cc092-a9f3-4e2d-b37d-a1e02132509a   ext4       
/dev/nvme0n1                                                       
/dev/nvme0n1p1   b6481137-e656-3bd0-f3ac-d16db16fe741   linux_raid_member rescue:0
/dev/nvme0n1p2   8d750efd-3e6d-a557-7cd3-4d63a8a97ae4   linux_raid_member rescue:1
/dev/nvme0n1p3   90e12ee6-caad-0590-a001-565990350608   linux_raid_member rescue:2
/dev/nvme1n1                                                       
/dev/nvme1n1p1   b6481137-e656-3bd0-f3ac-d16db16fe741   linux_raid_member rescue:0
/dev/nvme1n1p2   8d750efd-3e6d-a557-7cd3-4d63a8a97ae4   linux_raid_member rescue:1
/dev/nvme1n1p3   90e12ee6-caad-0590-a001-565990350608   linux_raid_member rescue:2

# ls -l /dev/disk/by-id" output
total 0
lrwxrwxrwx 1 root root  9 Jan  7 12:11 md-name-rescue:0 -> ../../md0
lrwxrwxrwx 1 root root  9 Jan  7 12:11 md-name-rescue:1 -> ../../md1
lrwxrwxrwx 1 root root  9 Jan  7 12:11 md-name-rescue:2 -> ../../md2
lrwxrwxrwx 1 root root  9 Jan  7 12:11 md-uuid-8d750efd:3e6da557:7cd34d63:a8a97ae4 -> ../../md1
lrwxrwxrwx 1 root root  9 Jan  7 12:11 md-uuid-90e12ee6:caad0590:a0015659:90350608 -> ../../md2
lrwxrwxrwx 1 root root  9 Jan  7 12:11 md-uuid-b6481137:e6563bd0:f3acd16d:b16fe741 -> ../../md0
lrwxrwxrwx 1 root root 13 Jan  9 08:53 nvme-eui.0025388891b099fa -> ../../nvme0n1
lrwxrwxrwx 1 root root 15 Jan  9 08:53 nvme-eui.0025388891b099fa-part1 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 15 Jan  9 08:53 nvme-eui.0025388891b099fa-part2 -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 15 Jan  9 08:53 nvme-eui.0025388891b099fa-part3 -> ../../nvme0n1p3
lrwxrwxrwx 1 root root 13 Jan  9 08:53 nvme-eui.0025388891b23f3f -> ../../nvme1n1
lrwxrwxrwx 1 root root 15 Jan  9 08:53 nvme-eui.0025388891b23f3f-part1 -> ../../nvme1n1p1
lrwxrwxrwx 1 root root 15 Jan  9 08:53 nvme-eui.0025388891b23f3f-part2 -> ../../nvme1n1p2
lrwxrwxrwx 1 root root 15 Jan  9 08:53 nvme-eui.0025388891b23f3f-part3 -> ../../nvme1n1p3
lrwxrwxrwx 1 root root 13 Jan  9 08:53 nvme-SAMSUNG_MZVLB1T0HALR-00000_S3W6NX0M800972 -> ../../nvme0n1
lrwxrwxrwx 1 root root 15 Jan  9 08:53 nvme-SAMSUNG_MZVLB1T0HALR-00000_S3W6NX0M800972-part1 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 15 Jan  9 08:53 nvme-SAMSUNG_MZVLB1T0HALR-00000_S3W6NX0M800972-part2 -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 15 Jan  9 08:53 nvme-SAMSUNG_MZVLB1T0HALR-00000_S3W6NX0M800972-part3 -> ../../nvme0n1p3
lrwxrwxrwx 1 root root 13 Jan  9 08:53 nvme-SAMSUNG_MZVLB1T0HALR-00000_S3W6NX0M810491 -> ../../nvme1n1
lrwxrwxrwx 1 root root 15 Jan  9 08:53 nvme-SAMSUNG_MZVLB1T0HALR-00000_S3W6NX0M810491-part1 -> ../../nvme1n1p1
lrwxrwxrwx 1 root root 15 Jan  9 08:53 nvme-SAMSUNG_MZVLB1T0HALR-00000_S3W6NX0M810491-part2 -> ../../nvme1n1p2
lrwxrwxrwx 1 root root 15 Jan  9 08:53 nvme-SAMSUNG_MZVLB1T0HALR-00000_S3W6NX0M810491-part3 -> ../../nvme1n1p3

[fulltilt]

das scheint irgendein Bug in gdisk zu sein ...
habe vorhin in einer V-Box mal getestet mit SW raid1
vor dem einbinden ins Raid habe ich das FS und Layout Überreste entfernt:

Code: Alles auswählen

mdadm --zero-superblock /dev/sdb1
mdadm --zero-superblock /dev/sdb2
mdadm --zero-superblock /dev/sdb3

dann:

Code: Alles auswählen

sfdisk -d /dev/sda | sfdisk --force /dev/sdb
mdadm /dev/md0 -a /dev/sdb1
mdadm /dev/md1 -a /dev/sdb2
mdadm /dev/md2 -a /dev/sdb3
grub-mkdevicemap -n
grub-install /dev/sda
grub-install /dev/sdb
update-grub
update-initramfs -u
reboot

wenn ich nun mit gdisk teste bekomme ich die selbe Fehlermeldung wie beim Live System:

Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.

Code: Alles auswählen

blkid /dev/sda
/dev/sda: PTUUID="01883ed3" PTTYPE="dos"
# blkid /dev/sdb
/dev/sdb: PTUUID="01883ed3" PTTYPE="dos"

hab das ganze zweimal getestet (alte disk FS gelöscht & neue disk) Raid funktioniert problemlos trotzdem haut gdisk diese Meldung ständig raus ...

Code: Alles auswählen

gdisk -l /dev/sdx

gdisk findet also eine invalid GPT obwohl vorher nie ein GPT auf den disks existiert hat.

[habakug]

Hallo,

gdisk enthält das Tool fixparts. Es wird empfohlen [1] es zu verwenden

Code: Alles auswählen

# sfdisk -d /dev/sdX > parts.txt
# fixparts /dev/sdX
[...]

If your disk has stray GPT data, you'll be told this, and given the opportunity to immediately erase the GPT data. If this is the disk's only problem, I recommend erasing the GPT data and then exiting by typing q, which will preserve your existing MBR data in its exact form.

Gruss, habakug

[1] http://rodsbooks.com/missing-parts/#fixparts

[fulltilt]

gdisk findet Überreste von GPT Layouts ohne das vorher ein GPT angelegt wurde oder in Verwendung war. Auch auf neuen unbenutzten virtuellen disks einer V-Box die explizit mit MBR angelegt wurden.
Daher gehe ich davon aus das die Überprüfung von gdisk fehlerhaft (defekt) ist.

[habakug]

Hallo,

die Fehlermeldung ist beabsichtigt [1]:

When starting gdisk on a disk with existing MBR or BSD disklabel partitions and no GPT, the program displays a message surrounded by asterisks about converting the existing partitions to GPT. This is intended to scare you away if you launch gdisk on the wrong disk by accident or if you don't know what you're doing.

gdisk ist laut Manpage ein "Interactive GUID partition table (GPT) manipulator". Warum verwendest du das Tool, wenn nur ein MBR gewünscht ist?
Für eine GPT gilt: "the normal state for a GPT disk is MBR: protective and GPT: present." [1].

Gruss, habakug

[1] https://www.rodsbooks.com/gdisk/walkthrough.html

[fulltilt]

OK Danke für die Info!
Ich habe es verwendet weil ich anfangs Zweifel daran hatte das die Layouts übereinstimmen, es wurde bei allen Tools dos angezeigt allerdings beo gdisk -l /dev/xxx wurde der Hinweis auf GPT Reste ausgegeben obwohl kein GPT auf den drives vorhanden war. Wie gesagt, gleiche Meldung tritt auch bei virtuellen V-Box drives auf nachdem ein neue oder existierende disk wieder ins SW raid eingebunden wird (beide mit MBR eingerichtet).
Der Output von gdisk ist also etwas irreführend und wäre nur zu beheben indem beide disks komplett neu installiert werden, das ist jedoch nicht der Sinn bei einem SW Raid.

[bluestar]

Der Output von gdisk ist also etwas irreführend und wäre nur zu beheben indem beide disks komplett neu installiert werden, das ist jedoch nicht der Sinn bei einem SW Raid.

Dann benutze doch bitte einfach das/die korrekten Tool(s), nur so verhinderst du das dich falsche Tools mit Meldungen in die Irre führen.

Wie mein Vorredner schon sagte/fragte:

Warum verwendest du das Tool, wenn nur ein MBR gewünscht ist?

Das Tool kann nichts dafür, dass es von dir ausgewählt/verwendet wird.

[fulltilt]

ja schon klar, nur zu dem Zeitpunkt bin ich noch davon ausgegangen das die DC Staff eventl anstatt MBR /GPT verwendet hat (siehe oben).
Deswegen musste ich auch mit gdisk prüfen ...