Re: checksum error in metadata node - best way to move root fs to new drive?

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2016-08-11 10:12, Nicholas D Steeves wrote:
> Why is the combination of dm-crypt|luks+btrfs+compress=lzo as
> overlooked as a potential cause?  Other than the "raid56 ate my data"
> I've noticed a bunch of "luks+btrfs+compress=lzo ate my data" threads.
I haven't personally seen one of those in at least a few months.  In 
general, BTRFS is moving fast enough that reports older than a kernel 
release cycle are generally out of date unless something confirms 
otherwise, but I do distinctly recall such issues being commonly 
reported in the past.
>
> On 10 August 2016 at 15:46, Austin S. Hemmelgarn <ahferroin7@gmail.com> wrote:
>>
>> As far as dm-crypt goes, it looks like BTRFS is stable on top in the
>> configuration I use (aex-xts-plain64 with a long key using plain dm-crypt
>> instead of LUKS).  I have heard rumors of issues when using LUKS without
>> hardware acceleration, but I've never seen any conclusive proof, and what
>> little I've heard sounds more like it was just race conditions elsewhere
>> causing the issues.
>>
>
> Austin, I'm very curious if they were also using compress=lzo, because
> my informal hypothesis is that the encryption+btrfs+compress=lzo
> combination precipitates these issues.  Maybe the combo is more likely
> to trigger these race conditions?  It might also be neat to mine the
> archive to see these seem to be more likely to occur with fast SSDs vs
> slow rotational disks.  Do you use compress=lzo?
In my case, I've tested on both SSD's (both cheap low-end ones and good 
Intel and Crucial ones) and traditional hard drives, with and without 
compression (both zlib and lzo), and with a couple of different 
encryption algorithms (AES, Blowfish, and Threefish).  In my case It's 
only on plain dm-crypt, not LUKS, but I doubt that particular point will 
make much difference.  The last test I did was when the merge window for 
4.6 closed run as part of the regular regression testing I do, and I'll 
be doing another one in the near future.  I think the last time I saw 
any issues with this in my testing was prior to 4.0, but I don't 
remember for sure (most of what I care about is comparison to the 
previous version, so i don't keep much in the way of records of specific 
things).