[dm-crypt] The future of disk encryption with LUKS2
sven at whgl.uni-frankfurt.de
Sat Feb 6 20:13:47 CET 2016
Vou are welcome.
Am 06.02.2016 um 15:20 schrieb Arno Wagner:
> Thanks, clearer now.
> On Sat, Feb 06, 2016 at 04:18:29 CET, Sven Eschenberg wrote:
>> Might be, or I was just unable to communicate my thoughst properly.
>> The first paragraph rather commented on Robert's post. He talked
>> about LVM and I wanted to point out that LVM is not a good example
>> of how to properly handle resizing, as it fails to properly resize
>> for multiple metadata locations. (A secondary header implies that
>> all changes on both headers need to be atomic and in sync. While
>> this is doable, LVM clearly shows, that it is not trivial, otherwise
>> it would certainly be available as feature by now).
>> The second paragraph commented on your statement regarding
>> filesystem resizing the way LVM handles it (lvm --resize). You
>> stated this would limit the possible filesystems in the dm-crypt
>> container where a resize could be done. I agreed that it is limited
>> to those supporting online resizing. LVM uses fsadm which in turn
>> uses the filesystem's API to do the resize operation. The operation
>> is then commenced by the fs driver. You already said before, that
>> you rather recommend to recreate the filesystem. If one goes this
>> path, then there is no need for a resize operation on dm-crypt's
>> side either. If you recreate the fs, then you can aswell just
>> recreate the dm-crypt container instead of resizing it.
> I think I did recommend that. At least that was the idea:
> 1. Do backup
> 2. Resize partition
> 3. Recreate LUKS container and restore backup
You indeed did. Right now the container resizes without any interaction
as the whole device simply is mapped. This of course has to change in
one way (or another) if multiple metadatacopies are used. And providing
a resize needs quite some work (in design and code). I wanted to point
this out, as I had the impression that some others thought it would be
trivial to keep the feature.
> Far less ways for this to go wrong. And unless 1. is broken,
> you can try again.
>> IMHO a dm-crypt resize operation only makes sense, if you plan to
>> resize the filesystem aswell. Otherwise just backup and recreate.
> I agree to that. So maybe to satisfy KISS, it would be preferrable
> to not even have container resize, even when the container becomes
> aware of its size, unlike now.
For safety, yes, dumping the resize feature would be smarter. Then
again, for those not faint at heart, why not give the option to do
online resizes. For big storage-containers backup+online-resize still
can safe you a lot of time (and downtime) afterall.
More information about the dm-crypt