[dm-crypt] The future of disk encryption with LUKS2

Sven Eschenberg sven at whgl.uni-frankfurt.de
Sat Feb 6 04:18:29 CET 2016


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.

IMHO a dm-crypt resize operation only makes sense, if you plan to resize 
the filesystem aswell. Otherwise just backup and recreate.

Regards

-Sven


Am 06.02.2016 um 03:58 schrieb Arno Wagner:
> It might be the time of night, but I have no idea what you are
> trying to say....
>
> Regards,
> Arno
>
> On Sat, Feb 06, 2016 at 00:51:07 CET, Sven Eschenberg wrote:
>> It should be noted here, that LVM is incapable to resize when
>> there'S multiple metadata areas (and that is certainly not a
>> coincidence).
>>
>> Arno, remember, that type of resizing usually only refers to
>> filesystems that can be resized online and which is done by the FS
>> itself (as in intriniscly). This is of course a limitation, but then
>> again, who'd want to resize a dmcrypt container instead of
>> recreating it, when using a filesystem that cannot be resized? That
>> does not make too much sense too me, cause recreating the dm-crypt
>> container is merely a single minor extra step when you recreate the
>> filesystem anyway.
>>
>> Regards
>>
>> -Sven
>>
>> Am 05.02.2016 um 16:57 schrieb Arno Wagner:
>>> On Fri, Feb 05, 2016 at 16:08:28 CET, Robert Nichols wrote:
>>>> On 02/04/2016 11:23 AM, Arno Wagner wrote:
>>>>> On the other hand, resizing a Luks container with a
>>>>> filesystem in there without killing that filesystem is
>>>>> already complicated enough that I usually just recomend
>>>>> a backup and recreation instead of a resize.
>>>>
>>>> Making an already difficult process more complex isn't going to
>>>> win many friends.  Sounds like what you need is a "--resizefs"
>>>> option like the one LVM's lvresize uses to invoke fsadm(8).
>>>
>>> And thereby limit what filesystem can be in there? That is
>>> a rather gross layering-violation and not a good idea.
>>>
>>> Do not forget that backup and restore need to be tested
>>> and the backup done regularly anyways if the data has any
>>> worth. I an not asking people to do anything new. (Well,
>>> except for those with only throwaway-data in their encrypted
>>> containers....)
>>>
>>> Regards,
>>> Arno
>>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt at saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>


More information about the dm-crypt mailing list