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