On 03/11/2009 03:24 AM, Jeremy Katz wrote:
On Tuesday, March 10 2009, David Cantrell said:
LVM possibilities seem to be open to discussion. As in, what
should (or did) we support. Here's what I have on my list as
possibilities:
What we supported in the past was shrinking LVs (and the filesystems on
top of them). Getting into the VG and PV shrinking game gets ...
"interesting" as you mention :)
Annoying is another word for it. :)
[snip]
So, out of the LVM possibilities, I would personally like to
restrict it to resizing a filesystem, which would shrink or grow
the underlying logical volume, volume group, and physical volume.
Working at the VG or PV layer seems useless in the installer.
Why resizing the underlying VG and PV when you resize the LV? If you
leave them the same size, there's still room for adding more LVs
Because my goal has been to create unallocated raw space on the device,
PED_PARTITION_FREESPACE[1].
If freeing up space in a VG is sufficient, I'm perfectly ok with that.
Basically, I was wanting to know how far I should go with resize and LVM.
I think the resize policy in anaconda should be to free up
unallocated space on disks rather than to free up possibly usable
space (as in, space in a volume group). If we do the latter, I
think we'd be asking for trouble.
Possibly... it's what we previously did, though, mostly because
otherwise the decisions about things like "which PV do you shrink in a
VG with multiple PVs" get ugly
Fair enough.
[1] For device types that libparted can see correctly.
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
