Thanks for your comments Michael!
I had not been thinking of removing the label entirely when I last read
the disklabel(8) manual page carefully so I had missed/forgotten the
'-D' option.
Once I'm finished sending this message I'll shut down the domU and try
that (after creating a backup copy of the current disk label).
I'm no longer confused by why access in the dom0 to the LV through the
device mapper device (a dm(4) device) doesn't honour the limits set by
the on-disk disklabel since of course this device doesn't have support
for partitions defined by labels.
I'm assuming (without yet having read any code) that indeed it is the
xbd(4) driver that's enforcing the size limits of the disklabel, just in
the way any traditional disk device driver would do. My mistake was
thinking of it more as a simple pass-thru device to access the back-end
LV in the dom0 and I hadn't really paid attention to the fact that it
supports partition sub-devices just as all disk drivers do.
At Sat, 23 Feb 2019 06:38:53 -0000 (UTC), mlelstv%serpens.de@localhost (Michael van Elst) wrote:
Subject: Re: extending LVM logical volumes for Xen root partitions is NOT so simple!
>
> woods%planix.ca@localhost ("Greg A. Woods") writes:
>
> >Basically I had doubled the size, and now it seems none of superblocks
> >fsck wants to read can be read (from the domU).
>
> Just changing the size of the LVM doesn't change the partitioning or
> the filesystem layout.
Well, yes, of course, thus the use of resize_ffs(8), which in my case
was from the dom0 and thus it ignored the disklabel.
> Ideally you'd need to access the LVM volume as a paritioned disk,
> but vnd doesn't support block devices yet. Just assuming things work
> because everything is aligned at offset 0 causes such problems.
Actually, no, since in my case, and as is recommended by many for use of
LVM, each LV is effectively a single partition, and is intended for use
in its entirety by one filesystem.
Indeed that's the root of my subject line -- the documentation (ch17 of
The NetBSD Guide in particular) makes no mention of putting disklabels
on logical volumes, or of adjusting diskabels when resizing LVs (an
explicit note in 17.8.3 mentions resizing the filesystem before/after
resizing the LV, but with no mention of disklabels); and with my prior
experience with LVM and similar of using one LV per filesystem I've
mistakenly made the assumption that the burden of managing per-LV
disklabels was entirely unnecessary.
> On a regular disk you wouldn't fsck the raw partition even when
> the filesystem partition starts at offset 0.
Well, that depends, I think. I've often used a whole disk as a single
filesystem container (especially on non-i386 systems by using the
automatically created 'c' partition), and in this case the "container"
in question already effectively a "partition" because it's a single
logical volume in a larger volume group, thus logically equivalent to a
partition on a disk.
While the ability to put a disklabel on a logical volume is perhaps some
indication of the generality of its implementation, I don't think it
normally makes much sense to think of logical volumes as full emulations
of a physical disk drive. I started using logical volume managers way
back when IBM's AIX first gained such a tool, and I've always thought of
a logical volume as a single "partition"-like container suitable only
for a single filesystem (or similar use, e.g. swap, or some raw-disk DB).
Perhaps though, and because of history and circumstance, many Xen admins
will be giving a single LV for each domU, or at least for each "system
volume" (perhaps with user data being additional LVs), and especially
with install tools like systinst this volume ends up as a partitioned
emulation of a whole disk. Of course then they're stuck with doing a
backup and re-install to change the size of any "system" filesystem
(root, possibly swap, /var, /usr/pkg, etc.), whereas by strictly using
one LV per filesystem or swap device, etc., then resizing one or all of
those system "partitions" is MUCH easier. (especially when on-disk
disklabels don't get in the way!)
> >Ideally I would like to see the OS handle all these issues automatically
> >somehow, though it wouldn't be the end of the world if there were
> >another step required to resize a root filesystem.
>
> It's no more different than changing a real disk.
Well there is a stark difference between the way the documentation
recommends using LVM without labels for filesystems and what's actually
required, especially for the specific case of a domU root filesystem
that is the result of using the norml method of doing the domU install
with sysinst and thus ending up with a labelled LV for the root FS.
Indeed so far I've found zero mention anywhere of any need to adjust the
on-disk disklabel when resizing any LVM-backed domU filesystem, so for
sure this is to some degree a documentation failure.
> Changing a disk size doesn't resize a partition or even resize a filesystem.
> After all, you could want to use that space for another partition.
Well, changing the LVM size does implicitly change the fictitious
disklabel.... And in theory "resize_ffs" does the rest, but of course
only if there isn't a stale on-disk disklabel getting in the way.
Perhaps if the fictitious label works even for all maintenance tools,
e.g. systinst (i.e. during upgrades), then the best option is to simply
zap the label during the initial install. My personal "Quick NetBSD
domU" instructions already include a step for pausing sysinst when it
asks for where to fetch sets in order to manually newfs and mount
additional xbd devices for partitions such as "/var" and "/usr/pkg"
before continuing; so adding another step to do the "disklabel -D xbd0"
should suffice. Eventually I'd like to modify sysinst to specifically
handle Xen domU+LVM installs with these additional steps. However I'm
still considering the relative merits (in an all-NetBSD hosting
environment) of doing the sysinst in the domU or in the dom0.
Which reminds me -- I now know where the on-disk label for my swap
partition came from -- I made it! My domU install procedure includes
instructions for changing the filesystem type in the label for the swap
device so that it can be automatically used by swapctl(8). I just
forgot to make the connection between editing the fictitious label and
the fact that writing it would of course store it on the device.
--
Greg A. Woods <gwoods%acm.org@localhost>
+1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgp9beStKTW32.pgp
Description: OpenPGP Digital Signature