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@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
