At Fri, 12 Mar 2021 23:27:28 -0000 (UTC), mlelstv%serpens.de@localhost (Michael van Elst) wrote:
Subject: Re: problems with GPT (and maybe dkctl wedges) on LVM volumes
>
> The LVM volume acts like a partition (or wedge), not a partitionable
> disk.
Welllll, in the end the LVM volume _is_ a partitionable disk in some
circumstances (e.g. when it is presented to a domU via an xbd(4)
device). Whether it is directly through dm(4) or via Xen through
xbd(4), block to block, i.e. all forms of access, it should be identical
(assuming the caveat you mention below about possibly different block
sizes doesn't come into play).
> ># dkctl /dev/mapper/rvg0-nbtest.0 makewedges
> >dkctl: /dev/mapper/rvg0-nbtest.0: makewedges: Inappropriate ioctl for device
>
> The LVM volume is not a disk.
But it says _is_ a (virtual) disk (i.e. dm(4) makes this claim, see
below)!
I agree that normally I think an LVM volume is best thought of as the
moral equivalent of a disk partition, but in fact it is effectively
presented as an independent chunk of "raw" storage, and so depending on
circumstances it should (and can!) be used as a partitionable disk
instead of just as a slice of a disk.
I don't necessarily want to use xbd(4) devices as partitionable disks,
but this is the way sysinst currently prefers to do things, and I _am_
trying to go more with the flow these days!
> - use device mapper directly (not LVM) to subdivide dm devices into
> smaller dm devices to access the guest partitions.
That seems ever more convoluted than just treating an LVM volume as a
"disk" (which is itself already using dm(4) as I understand things, and
so as per dm(4), presenting virtual disks, see below).
> - create a ccd(4) disk on top of a partition or LVM volume (with a
> recent kernel). The ccd device is a disk again and partitioning
> works on it. Some people use raid(4) instead, but ccd(4) is easier.
Hmmm.... there was talk at one time of trying to use a vnd(4) to foil
the system into thinking an LVM volume was a whole partitionable device,
but apparently that didn't work at the time. However to me the very
thought of having to add another layer of misdirection to the mess is
very counter-intuitive and undesirable.
LVM should be, in and of itself, fully sufficient and able bundle and
carve any combination of underlying physical devices into equally usable
but more flexible "virtual" devices.
At least that's the way the first implementations of the things calling
themselves "LVM" worked, e.g. on AIX. Unfortunately I haven't the
patience to see if the Linux variant can do the same.
After all, the description of dm(4) opens with the words:
The dm driver provides the capability of creating one or more virtual
disks based on the target mapping.
If "disks" doesn't mean "disks", then that seems kind of half-baked to
me. It seems to me it should be possible to map an array of partitions
via a device driver such as dk(4) no matter what the underlying device
is.
> There are still two caveats.
>
> The DomU xvbd driver always pretends that the disk has 512 byte
> sectors which is bogus. But Dom0 sees the real disk and presents
> disk and partitions as having the real (logical or emulated) sector
> size. If this isn't the same, you cannot access the guest filesystem
> from DomU.
That's interesting, but I don't think it is relevant in this particular
case, as so far as I know there's no mismatch in sector size occurring
(my underlying device is an mfi(4) RAID controller, via an sd(4) device,
which in turn claims to be offering "512 bytes/sect".
It would simply appear to me that there's a basic flaw of some sort in
the algorithm used by gpt(8) (and the kernel) in finding the relevant
parts of a GPT table that it clearly can mostly see already. What's
confusing to me though is why there is any difference to how these
things behave when using an xbd(4) interface in a domU as opposed to
when seen directly at the dm(4) level in the dom0. My assumption was
that xbd(4) is just passing blocks back and forth -- the access through
dm(4) devices should be entirely identical no matter whether done
directly or through the Xen layers.
However I do know that there are a number of hairy and often incomplete
assumptions built into some virtual devices, particularly where it comes
to dealing with partitioning. I had assumed that the likes of GPT,
dm(4), dk(4), et al would make things even more orthogonal, but perhaps
I'm mistaken.
> Even when you can access the filesystem, you must not mount it
> concurrently on Dom0 and DomU (both mounting read-only is ok).
Of course not!
--
Greg A. Woods <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpn9nS9AgQnC.pgp
Description: OpenPGP Digital Signature