Re: BTRFS, SSD and single metadata

[Russell Coker <russell@coker.com.au>]

On Mon, 16 Jun 2014 07:23:14 Austin S Hemmelgarn wrote:
> I'd personally stay with the DUP profile, but then that's just me being
> paranoid.  You will almost certainly get better performance using the
> SINGLE profile instead of DUP, but this is mostly due to it requiring
> fewer blocks to be encrypted by LUKS (Which is almost certainly your
> primary bottleneck unless you have some high-end crypto-accelerator card).

On my Q8400 workstation running BTRFS over LUKS on an Intel SSD the primary 
bottleneck has always been BTRFS.  The message I wrote earlier today about 
BTRFS fallocate() performance was on this system, I had BTRFS using kernel CPU 
time for periods of 10+ seconds without ANY disk IO - so LUKS wasn't a 
performance issue.

So far I've never seen LUKS be a performance bottleneck.  When running LUKS on 
spinning media the disk seek performance will almost always be the bottleneck.

The worst case for LUKS is transferring large amounts of data such as 
contiguous reads.  In a contiguous read test I'm seeing 120MB/s for LUKS on a 
SSD and 200MB/s for direct access to the same SSD.  That is a reasonable 
difference, but it's not something I've been able to hit with any real-world 
use while BTRFS metadata performance is often an issue.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/