[This is in a separate message because it could be a distraction. I'm just tossing this stuff as food for thought, but don't want to derail.] Given all the complexity about "how do we do this atomically," there's also the really simple idea of just writing several copies of the header, perhaps one right after the other, and just -voting-. (The ITS operating system, which ran on PDP-10's back in the 70's and 80's, did precisely this with its directories---it replicated its directory structure onto every disk pack in parallel, and when the machine came up, it simply did a majority vote amongst the packs.) This gives LUKS lots of redundancy and a mechanism to pick the right header that's really easy to analyze for correctness. I have nothing against generation counts---they would help win a tie from an unfortunate corruption that leads to an even number of survivors ---but voting may help with the whole "how do we know when disks do their writes" issue by encouraging lots of redundant copies. P.S. My other worry with "header at the end" concerns deliberate overwrite. If I have a LUKS container and I want to be absolutely sure that I've wiped all keys before I discard the device,* writing a few meg, or even a gig, to the front of it guarantees this. With a header at the end, I need to be able to figure out where that header is. (I can't count on always having the luxury of using LUKS itself to wipe every keyslot when discarding a disk.) Sure, I can do the math and issue the correct dd into the container at the right offset, but it encourages mistakes. * (I can think of several scenarios whereby someone may have had access, authorized or not, to a pasphrase, so I want to ensure that such knowledge can't do them any good once I let the disk out of my physical possession.) _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
