Steve Costaras schrieb:
Ok, so basically this is something that is not handled well/not thought
out then by at least LUKS, if what you're saying is the future path to
put headers at the beginning and end of the drive (which with the swap I
indicated this would have the 'end' header in the 'middle' of the drive
as it would have been expanded by the underlaying hardware raid) it's
not something that I would want to put into production use.
At least not until there is a process in place that will allow the user
to tell dmcrypt to re-check the size of the physical volume and update
the headers automatically. (similar to say pvresize for lvm2 or jfs's
resize mount option or xfs_growfs).
Otherwise it would be way too involved when dealing with hundreds of
drives for the administrators.
cryptsetup-luks development seems to have stalled a bit, at least
according to the SVN logs and release frequency. However, I found this:
http://code.google.com/p/cryptsetup/wiki/LUKSSpec20BrainStorming
Quote: "Meta-Data redundancy
Make the LUKS header redundant by putting a copy at the end of the
partition too. Introduce luksResize that moves that header. Introduce
luksRepair that repairs either the front-header from the back or vice
versa. Introduce a switch to all LUKS commands to explicitly utilize one
of these two headers.
Introduce size of the bulk data
TODO: Do the math what this means for effective key revocation."
---------------------------------------------------------------------
dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx
