On Sun, Aug 26, 2012 at 5:21 PM, Arno Wagner <arno@xxxxxxxxxxx> wrote: >> I think the resync did no damage because it only wrote to the new >> disk; the originals only had to be read. > > I am not sure. Only recreating parity (my original though) > would also be a valid approach for a new array, and that is > what you were creating. But I specified --assume-clean and was creating a degraded array (so a resync wouldn't even have been possible at that point). I then added a new drive to a supposedly clean, but degraded array, so the resync should only have written to that. >> I was thinking that maybe I could try to assemble the (copies of the) >> original array with the 0th, 2nd and 3rd drive, leaving the 1st out >> initially and then re-add it, allowing RAID5 to sync the data to it, >> thereby hopefully regenerating the LUKS metadata. However, this won't >> work either. >> >> My array used the default left-symmetric layout, which afaik is: >> >> D0 D1 D2 P0 >> D4 D5 P1 D3 >> D8 P2 D6 D7 >> ... >> >> D1, D2 and P0 are damaged. Everything else is intact. >> >> So even omitting D1, the data that would be used to reconstruct it >> would be incorrect. > > No idea. Well, P0 is the parity block computed from D0, D1 and D2. Since D1, D2 and P0 are damaged, there is no way to use the parity to reconstruct the contents of any of these blocks. >> > Now resync for RAID5 only writes >> > the parity of all other disks to one. >> >> Not quite. If you add a missing disk, it will contain data as well as >> parity after the resync. The parity will be computed based on the data >> on the other disks as you said, while the data will be computed as a >> function of the data and the parity on the other disks. >> >> > LUKS keyslots are 128kiB in size. So you may still be in luck, >> > but this is going to take a lot of time to test out and sounds >> > rather unlikely. >> >> All chunks are 64k long. The first keyslot started somewhere in the >> first part of D0, covered all of D1 and ended in the first part of D2. >> It's gone for sure, becuase part of D1 got overwritten. If next >> keyslot followed immediately, it covered D3 and ended in D4. It was >> likely also overwritten because a raid superblock was written to >> D2+4k. However, the third keyslot had to start in D4 (or even D5, >> depending on the specific layout; D0+D1+D2+D3 together only have room >> for two keyslots). >> >> Therefore, the third keyslot should still be intact. >> >> Now, how do I get to it? > > Ah. Use the info in the FAQ and RAID geometry to extract it, and > place it in a file (starting with the intact header) at the correct > offset. O-kaaaaay... I'll try that and come back if I have specific questions. >> Any suggestions? > > Put the pieces from the removed disk into a file at the correct > offsets (where they were when the array was assembled) and try > with that. So, to reiterate: I use luksHeaderBackup to dump the entire header of the reassembled, but corrupted array to a file. I then extract keyslot #2 from the pristine disk and write it to the offset in the header file where keyslot #0 should be. Then I try to luksOpen my array with the modified header file. Is this what you're suggesting? Thanks a lot for the help, btw! Andras _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
