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

Sven Eschenberg sven at whgl.uni-frankfurt.de
Sat Feb 6 00:51:07 CET 2016


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
>


More information about the dm-crypt mailing list