Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 03/08/2011 04:51 PM, Felix Frank wrote: > >> While kpartx works I'm wondering why it is necessary. I would expect >> /dev/drbd1 to behave like a regular block device and the partitions to >> show up if not after writing the new table then at least after a reboot. >> Eventually I will probably go for an LVM setup but since this is >> supposed to become part of a pacemaker cluster and I'd like to build >> this up one step at a time I'd first like to get a filesystem on a >> regular partition going before I add the LVM layer in between. > > Hi, > > while partitioning a partition is possible and rather straight-forward, > it sure isn't standard practice. I wasn't actually suggesting to create "partitions in partitions" I just wasn't aware that the drbd device nodes are partitions and not basic block devices (like i.e. the /dev/xvdN nodes that xen adds). That certainly explains the behavior I'm seeing. > Besides, what do you expect from the kernel? Descending arbitrary levels > of partitioning and adding nodes for the partitions thus found...by what > system? > > Graphically: What major/minor numbers would you have associated with > your third primary partition's first logical partition's second primary > partition's first primary partition? > > Also, please make sure that replication actually works when you mount > your "inner partitions" this way. I think it should, but I might be wrong. I'm sure one could make this work but I don't intend to try it. I've seen people use logical LVM volumes as physical volumes for new volume groups which *seemed* to work though I didn't know for sure because I was too busy trying to get out of there. Always fun to see these kinds of M.C.Escher-esque topologies....as long as I don't have to maintain them :) Regards, Dennis