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
partially written.
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?
Regards
-Sven
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.
Regards,
Arno
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.
Regards
-Sven
Am 06.02.2016 um 20:09 schrieb Michael Kjörling:
On 6 Feb 2016 19:56 +0100, from sven@xxxxxxxxxxxxxxxxxxxxx (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@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
