[blivet:rhel7/master 3/3] Set up Blivet.resizeDevice() to handle LUKS devices (#1076055)
dlehman at redhat.com
Thu Sep 25 14:59:30 UTC 2014
On 09/24/2014 02:16 PM, Anne Mulhern wrote:
> ----- Original Message -----
>> From: "David Lehman" <dlehman at redhat.com>
>> To: anaconda-patches at lists.fedorahosted.org
>> Sent: Wednesday, September 24, 2014 12:21:53 PM
>> Subject: Re: [blivet:rhel7/master 3/3] Set up Blivet.resizeDevice() to handle LUKS devices (#1076055)
>> On 09/24/2014 11:12 AM, mulhern wrote:
>>> Previously, resizeDevice() could not resize a LUKS device.
>>> A LUKS device is just a kind of veneer over its slave device and is the
>>> only kind of devices such that device.raw_device is not device.
>>> blivet does not currently implement a resize() method for LUKSDevice and in
>>> the general case, it is always necessary to resize the raw_device in order
>>> to resize the LUKSDevice itself. However, when blivet is able to resize the
>>> LUKS Device, which at this point is exactly when the LUKSDevice does not
>>> yet exist and its raw_device is resizable, resizeDevice() should be able to
>>> do it.
>> Why not just be more careful in anaconda which device you pass to
>> resizeDevice? This all seems like dangerous blurring of lines in blivet
>> to avoid a few LOC in anaconda. I don't object to adding comments or
>> checks, but making arrangements to allow calling resizeDevice on a
>> non-existing device seems like the wrong way to go. I think this was my
>> basic issue with the last set you posted for this bug.
> I think it's the existence of a LUKSDevice that has muddied the waters.
> For this particular problem, it would be easier if we had represented an
> encryption of a device in some other way.
> My feeling is that, since resizeDevice() is a high-level method, and
> blivet has other users than anaconda, it should
> generate the appropriate set of actions required to resize any device
> that it can manage this task for.
> Since a LUKSDevice is a Device, that ought to include LUKSDevices.
resizeDevice is not intended to schedule resize actions at multiple
levels. If we add support for resizing LUKS, the way to resize one will
be to resize the backing device and the LUKS device separately. The
order will depend on whether the devices are growing or shrinking.
Similarly, it is not possible (or intended or planned) to call
resizeDevice on an LV in a full VG with some free space adjacent to one
of the PVs on disk and have it generate the full set of actions to grow
the PV, then grow the VG, then grow the LV. While that might be nice,
it's a significant undertaking. For now, that's not how blivet works in
general (the exception being the device factory classes which, btw,
might be a logical place for such high-level resize functionality).
> The basic problem, as I understood it, with my previous solution,
> was that it generated a ResizeAction()
> for a non-resizable device, which it no longer does.
> Alas, anaconda patch set already has plenty of LOC in it and will
> probably develop more now that the issue with on_device_type_changed()
> is looking so problematic.
> One thing that I think it is wrong to do, is to decide,
> in anaconda, how much extra space the slave device needs, more
> than the size the user specified, in order to make the LUKS device
> end up the size the user specified. That should be decided in blivet
> and that's another reason why I like this change to resizeDevice().
I tend to agree, but I still don't like the change to resizeDevice. We
have to find a better way or just deal with the consequence described below.
> However, if you're happy to make the slave device the size that user specified
> for the LUKS device, then I can withdraw patch (3) in this set,
> and just call resizeDevice() on use_dev, instead of on device.
> in anaconda patch 5. But that difference may be visible to the user
> in 2 decimal places of precision, i.e., they specify 12 GiB for the
> LUKS device and only get 11.99 GiB displayed.
> - mulhern
> anaconda-patches mailing list
> anaconda-patches at lists.fedorahosted.org
More information about the anaconda-patches