Hi Milan,
While I understand your arguments, many of these issues can be addressed
more or less easily. If we talk about really complex setups, we
hopefully consider these not average user cases and non average users
are always on their own, at least to some extent.
Concerning GPT, it already collides with mdadm metadata, while mdadm
metadata at the start of device does have it's own serious issues aswell.
And to be honest, there is no way around the user knowing the layering
anyway and letting him/her do the necessary steps in the correct ordering.
The current LVM man pages still suggests that resizing with multiple
metacopies is not working, if it does work nowadays, the man page needs
fixing ;-).
BTW: Personally I think that one thing in the blockdevice stack was
screwed up severely: Always have information on the upper layer in the
lower layer - That would eliminate most issues. On the lowest layer we
do have that information (PARTUUID/PARTTYPE), it is just mostly ignored.
Regards
-Sven
Am 10.02.2016 um 09:37 schrieb Milan Broz:
On 02/10/2016 12:35 AM, Arno Wagner wrote:
On Tue, Feb 09, 2016 at 23:08:19 CET, Lars Winterfeld wrote:
On 08.02.2016 22:51, Milan Broz wrote:
[Just note to already crazy discussion here - there will be NO LUKS header
at the end of device. Been there with another storage project and
just no - it is not worth problems it causes.]
Out of curiosity: what were those problems?
I think the real problem was mentioning here several times -
the device size sometimes changes and you have no real control over it.
People resize partition tables, logical volumes, use dd from
smaller disk to bigger (and vice versa but that's another story ;-)
Then you have not always chance to properly wipe out old header, and
in the LUKS case it is additional security risk.
(If you do not wipe additional space it is not so big problem.)
Also note that GPT stores backup header near the end of device,
I can imagine various semi-destroyed headers by that as well.
In case of a "forensic" recovery (you are trying to recover some
partially wiped disk) it complicates thinks even more (should
we expect that a second header somewhere on the device has correct device
size in it or it is just old header and the real one was destroyed?)
(If we have sequence if or epoch in such metadata - what to do
if there is more recent version - because some people tried to recover
with wrong device size (common mistake to try recovery before thinking
of the real problem)? What if it is an older metadata from some
previous install - can we expect always different UUID?)
From the LUKS POV it means that there is no need to change logic
of backup and recovery of header (just replace header, no need to
play magic with writing to device end).
With external scripts (and even programs compiled without proper flags)
you have even bigger chance to screw it up for large devices
when calculating header position because of limited integers handling
(note getsize/getsize64 in blockdev command for example).
The implementation is more complicated but that's not the reason
to reject it (despite I prefer simpler code).
IIRC for lvm2 the resize with redundant metadata (located near the end of PV)
was disabled for some time (code was not complete to handle it)
but today it should work (just FYI).
...
Was the problem confusion/complexity because this
layering-sheme was violated?
That is another problem - during storage stack resize you require user
to do various complicated steps. If a layer just takes current device size
without any complicated steps it effectively limits area for error.
(Well, it can be exact opposite in some situations but I expect people are
more extending devices than shrinking it.)
(In current LUKS2 metadata we can store segment size, so we can limit
device size in header but this is meant for some internal segment handling
like reencryption which requires several segments of sliding window
with limited size. Default is still "use current device size".)
So my reason to not use header near the end of the device is mainly
that security risk of possibly old keyslot material on device.
Milan
_______________________________________________
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
