Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi Yannis, thank you for your answer. I don't think that the first
"partition" is where drbd stores metadata for two reasons:
1) I'm using internal metadata and, as suggested by the drbd documentation:
"Configuring a resource to use internal meta data means that DRBD stores
its meta data on the same physical lower-level device as the actual
production data. It does so by setting aside an area at the *end* of the
device for the specific purpose of storing metadata."
2) the /dev/sde1 device appears only after I create an LVM partition on the
initiator. This means that there is a really "overlap" between /dev/sde1
and /dev/drbd2 where /dev/sde1 is an LVM partition created on the initiator
and /dev/drbd2 is a device created on top of /dev/sde from the drbd cluster.
I did another test:
- I created a partition (type = LINUX, NOT LVM!) on top of /dev/sdd, so I
have /dev/sdd1 as a new device
- I put /dev/drbd2 on top of /dev/sdd1
- /dev/drbd2 is used as a backstores in targetcli
- from the initiator I create another partition (LVM)
Now it seems all correct from the drbd nodes point of view:
[root at san2drbdrep ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
......
sdd 8:48 0 10G 0 disk
└─sdd1 8:49 0 10G 0 part
└─drbd3 147:3 0 10G 0 disk
.....
[root at san2drbdrep ~]#
I'm sorry if device names doesn't correspond, but I used a test environment
now.
As you can see, now I have /dev/sdd1 on top of /dev/sdd and /dev/drbd3 on
top of the partition /dev/sdd1. Furthermore, even though I create an LVM
partition on top of /dev/drbd3 (from the initiator), lsblk doesn't show me
because I think that lsblk checks only first 2048 sectors on the disk. But
this is only a my idea, I need to check. Finally, from the drbd nodes I can
see also the LVM partition is I use fdisk:
[root at san2drbdrep ~]# fdisk /dev/drbd3
Welcome to fdisk (util-linux 2.23.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/drbd3: 10.7 GB, 10736005120 bytes, 20968760 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
Disk label type: dos
Disk identifier: 0x482a0701
Device Boot Start End Blocks Id System
/dev/drbd3p1 2048 20968759 10483356 8e Linux LVM
Command (m for help): q
[root at san2drbdrep ~]#
Another interesting question is: Why I don't see vg and lvs on top of
/dev/drbd3 from the drbd node with vgscan and lvscan? But This is not a
drbd question so I think I have to ask on the LVM mailing list.
So, the problem with this solution is that I cannot enlarge the drbd
device, but I don't need this. I'm focused on data alignment and
performance.
Anyway, I'd like to know if this is the right way to do this. In general it
seems to me that using a raw device as drbd backend is not a good idea even
though it is possible.
Thank you,
Marco
2017-03-25 14:57 GMT+01:00 Yannis Milios <yannis.milios at gmail.com>:
>
> Not 100% sure but the first 'partition' could be where drbd stores
> metadata?
>
> Your setup should be fine as long ad you can deal in an easy manner with
> future resizing of the backing device (sde).
>
> Yannis
>
> root at iscsi2 ~]# lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> ........
> sde 8:64 0 3,7T 0 disk
> ├─sde1 8:65 0 3,7T 0 part
> └─drbd2 147:2 0 3,7T 0 disk
> --
> Sent from Gmail Mobile
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20170326/aaa32073/attachment.htm>