> Did I understand your use case correctly? Yes! Thank you very much for this proposal :) It's much better than the two-token system I'm currently using. Still, I wonder if it's possible to get this entirely inside libcryptsetup: It can do multiple changes to metadata internally, but doesn't expose this in the API. There might be a relatively simple way to expose transactions: It should be possible to implement an atomic header restore if enough space is available in the keyslots binary area of the target of the restore. 1. Lock the target. 2. Iterate over the metadata in the backup/source header. For each allocation in the keyslots binary area in the backup header, perform an equally-sized allocation in the target header. This can fail if not enough space is available in the target header (for both its current allocations and the allocations from the backup header). 3. Adjust the backup header json metadata in memory to refer to the new allocations in the target header. 4. Copy the contents of the backup header keyslots binary area to the new allocations in the target header. Assuming some form of atomic writes (e.g. sector-size writes), this should be safe since we don't modify the content of the existing allocations in the target header keyslots binary area. At most, we're overwriting them with the same content. 5. Sync. 6. Overwrite primary header + json in the target. 7. Sync. 8. Optional: wipe the old allocations in the target binary keyslots area. 9. Optional: Sync. 10. Overwrite secondary header + json in the target. 11. Sync What worries me a bit is that you can fail between 7 and 11 and leave some of the old binary keyslots unwiped. This wouldn't be a concern if a repair operation that restores the second header from the first wipes the unused binary keyslots. There is potential for optimization of 2 and 3: diff the binary areas and only work on the difference. Additionally, if you create the backup header by doing all the keyslot additions first, and then remove other keyslots, the diff between backup and target will be disjunct, and restore won't fail due to size constraints. What do you think? Thanks again, Robert _______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
