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@xxxxxxxxx> 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).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
