From: PePa <peter@passchier.net>
Date: Tue, 18 Mar 2014 22:43:52 +0000 (UTC)
Message-ID: <loom.20140318T231540-552@post.gmane.org>
References: <loom.20140312T000413-75@post.gmane.org>
 <20140312005412.GA25009@tansi.org> <loom.20140312T222042-236@post.gmane.org>
 <20140313002938.GA31353@citd.de> <20140313013154.GA5434@tansi.org>
 <53215176.7000103@gmail.com> <loom.20140313T083620-530@post.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt]
	=?utf-8?q?cryptsetup-reencode=3ALUKS-=24=7BUUID=7D=2En?=
	=?utf-8?q?ew_is_too_small?=
To: dm-crypt@saout.de

PePa <peter@...> writes:
> I'll report back..!

So, I proceeded with:
cryptsetup-reencrypt -c aes-xts-plain64 -s 512 -h sha512
--reduce-device-size 4MiB /dev/sda4

The main problem was, at 99.4%, it stopped reencrypting due to I/O-errors... 

[The main way to catch this would be to do: badblocks -n /dev/sda4]

On Milan's advice I tried resuming:
cryptsetup-reencrypt --debug /dev/sda4
[Resuming is possible when the three .log .new .org files are still in the
running directory.]

It kept encountering I/O-errors. I used ddrescue to make a full copy, and
resumed on the copy, which finished fine, and all the file systems on the
LVM volumes were intact. I ended up copying this back to the original disk,
but I did a badblocks -n on it first, and it reported 5 errors.
This also opened fine with luksOpen, I fschecked the lvm volumes and they
were OK. I should probably do another badblocks -n to see if the write made
the drive firmware to deal with the badblocks.

Main take-aways:
- Check with "badblocks -n" before starting
- It would be great if after an I/O-error the bad block could be singled out
so that it can be read with ddrescue, and copied back.

Peter