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