[dm-crypt] The future of disk encryption with LUKS2
sven at whgl.uni-frankfurt.de
Mon Feb 8 01:25:31 CET 2016
I know that mdraid uses an events counter and checksum, probably Neil
Brown could clarify on the amount of updates. Never had problems either,
then again I think that mdraid signatures are by a magnitute smaller
than a LUKS header (mdadm signature/header is 1 sector). The checksum of
course is a good idea, to detect if the 'newer' header is corrupted or
Concerning disks, I thought with ACS2/ATA-8 real write barriers were
introduced. On the other hand I've seen disks returning successfull
reads with long zero-burst-errors undetected - no fun. I always wondered
how a HDD exactly behaves when power fails, while a sector is in
transit. My best hope is, that the CRC at the end of the sector does not
match and an error is returned on the next read?
Am 08.02.2016 um 00:05 schrieb Arno Wagner:
> Incidentally, this is the way Linux md-RAID checks whether
> elements are in sync on RAID assembly. I don't know how
> reliable and often md-RAID updates the counters, but I
> have not run into problems so far.
> For the LUKS header, a classic 2-phase commit would
> not be a problem. Disks do lie about having flushed
> buffers to disk (this world being pretty imperfect, in
> particular with regards to its inhabitants), but
> with some sensible delays that any header updates need
> anyways, this should be pretty reliable.
> On Sat, Feb 06, 2016 at 20:18:02 CET, Sven Eschenberg wrote:
>> Okay, I see, for simple updates a counter could indeed be sufficient
>> to ensure consistency by bringing the header with lower counter in
>> sync with the other one.
>> Am 06.02.2016 um 20:09 schrieb Michael Kjörling:
>>> On 6 Feb 2016 19:56 +0100, from sven at whgl.uni-frankfurt.de (Sven Eschenberg):
>>>> Hopefully I did not miss any step and yes, it is not THAT
>>>> complicated as there is no concurrency involved, but the
>>>> transactions for resizing need to be crafted carefully.
>>> I agree, it gets more complicated when resizing a container. I was
>>> considering primarily the normal use case of a container that isn't in
>>> the process of changing its size.
>> dm-crypt mailing list
>> dm-crypt at saout.de
More information about the dm-crypt