Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hello DRBD-users We have been using DRBD for nearly a year now, and have enjoyed the many benifits of it tremendously. However, we are trying to set up a new set of DRBD-enabled servers with slightly higher performance. We especially need read performance and higher seek performance, so we want to go with a RAID-1 on the primary server. We are aware that DRBD can't go faster than the slower of the two servers, but since the secondary server only needs to replicate the writes, this is not an issue for us, I believe. The setup we want is the following: Primary: 2 x 1.5TB SATA in RAID-1 (/dev/md1 (sda2, sdb2)) Secondary: 1 x 1.5TB SATA (/dev/sdb2) DRBD: 1 x 1.5TB (/dev/drbd1 from /dev/md1(pri) and /dev/sdb(sec)) Seems to work fine. However, we would like to use LVM on top of the DRBD disk. When I issue the pvcreate command, it works, but pvdisplay gives me the following: # pvcreate -vv /dev/drbd1 Setting global/locking_type to 1 File-based locking selected. Setting global/locking_dir to /var/lock/lvm Locking /var/lock/lvm/P_orphans WB /dev/drbd1: No label detected /dev/drbd1: size is 2914640640 sectors metadata/pvmetadatasize not found in config: defaulting to 255 metadata/pvmetadatacopies not found in config: defaulting to 1 /dev/drbd1: size is 2914640640 sectors Set up physical volume for "/dev/drbd1" with 2914640640 available sectors Scanning for labels to wipe from /dev/drbd1 Zeroing start of device /dev/drbd1 Writing physical volume data to disk "/dev/drbd1" /dev/drbd1: Writing label to sector 1 Physical volume "/dev/drbd1" successfully created Unlocking /var/lock/lvm/P_orphans # pvdisplay /dev/drbd1 "/dev/md1" is a new physical volume of "1,36 TB" --- NEW Physical volume --- PV Name /dev/md1 VG Name PV Size 1,36 TB Allocatable NO PE Size (KByte) 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID cRN1vb-T3pe-x85L-Ww0I-9DXf-7cSF-d6PAzW Yes, you read that right. It says /dev/md1. At this point I'm not sure if this is a minor naming bug, or a major data corruption bug? I'm sure that if the device is changed without updating the metadata, it will potentially destroy data. Can anybody explain this? I sure looks like a bug in the block layer, but is it related to DRBD? Or is is entirely benign? -- Med venlig hilsen / Best regards Christian Iversen Sikkerhed.org ApS Fuglebakkevej 88 E-mail: support at sikkerhed.org 1. sal Web: www.sikkerhed.org DK-2000 Frederiksberg Direkte: ci at sikkerhed.org