Hi Arno,
Vou are welcome.
Am 06.02.2016 um 15:20 schrieb Arno Wagner:
Thanks, clearer now.
On Sat, Feb 06, 2016 at 04:18:29 CET, Sven Eschenberg wrote:
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.
I think I did recommend that. At least that was the idea:
1. Do backup
2. Resize partition
3. Recreate LUKS container and restore backup
You indeed did. Right now the container resizes without any interaction
as the whole device simply is mapped. This of course has to change in
one way (or another) if multiple metadatacopies are used. And providing
a resize needs quite some work (in design and code). I wanted to point
this out, as I had the impression that some others thought it would be
trivial to keep the feature.
Far less ways for this to go wrong. And unless 1. is broken,
you can try again.
IMHO a dm-crypt resize operation only makes sense, if you plan to
resize the filesystem aswell. Otherwise just backup and recreate.
I agree to that. So maybe to satisfy KISS, it would be preferrable
to not even have container resize, even when the container becomes
aware of its size, unlike now.
Regards,
Arno
For safety, yes, dumping the resize feature would be smarter. Then
again, for those not faint at heart, why not give the option to do
online resizes. For big storage-containers backup+online-resize still
can safe you a lot of time (and downtime) afterall.
Regards
-Sven
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
