[dm-crypt] The future of disk encryption with LUKS2
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.
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
More information about the dm-crypt