Make cryptsetup-reencrypt resistant to unexpected hardware failure
For the past couple of days, I have been working on cryptsetup-reencrypt source code and hoping to find a way to make cryptsetup-reencrypt resistant to unexpected failure. I think the reason reencrypt might lose data after failure is that the reencrypt/encrypt/decrypt process could read and overwrite the same data range between write log commits. This makes me wonder if we can always have a spare space (no smaller than reencrypt block size) to decouple the read and overwrite block between log commits with "--use-fsync" which commits log after overwriting every block.
For example, if we try to add LUKS encryption to not yet encrypted device, we could use this command after we shrinks the filesystem for at least 4096 sectors.
cryptsetup-reencrypt /dev/sdb1 --new -B 2 --reduce-device-size 4096S --use-fsync
In this case, since data have been shifted for 4096 sectors (2MBytes) and block size is limited to 2MB, we should not have any data loss even if we force reboot during the process.
I am aware of that you guys has already been working on an online re-encryption tools which solves this issue, but I still want to know if I am missing anything about how to make this offline tool resistant to unexpected failure.