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 -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
