Re: slowness when cp respectively send/receiving on top of dm-crypt

On Mon, Nov 30, 2015 at 6:02 AM, Duncan <1i5t5.dun...@cox.net> wrote: >>> What are you using to tell you it has 1018391 extents? If you're using >>> filefrag, it's known not to understand btrfs compression, which uses >>> 128 KiB (pre-compression size, I believe, tho I'm not absolutely >>>

Re: slowness when cp respectively send/receiving on top of dm-crypt

On Sun, Nov 29, 2015 at 6:31 AM, Duncan <1i5t5.dun...@cox.net> wrote: > What are you using to tell you it has 1018391 extents? If you're using > filefrag, it's known not to understand btrfs compression, which uses 128 > KiB (pre-compression size, I believe, tho I'm not absolutely positive) >

Re: slowness when cp respectively send/receiving on top of dm-crypt

Henk Slager posted on Sun, 29 Nov 2015 20:29:49 +0100 as excerpted: > On Sun, Nov 29, 2015 at 6:31 AM, Duncan <1i5t5.dun...@cox.net> wrote: > >> What are you using to tell you it has 1018391 extents? If you're using >> filefrag, it's known not to understand btrfs compression, which uses >> 128

Re: slowness when cp respectively send/receiving on top of dm-crypt

On Sat, 2015-11-28 at 11:34 -0700, Chris Murphy wrote: > It sounds to me like maybe LUKS is configured to use an encryption > algorithm that isn't subject to CPU optimized support, e.g. aes-xts > on > my laptop gets 1600MiB/s where serpent-cbc gets only 68MiB/s and pegs > the CPU. This is reported

Re: slowness when cp respectively send/receiving on top of dm-crypt

Hi Chris, some more comments after I have done some fresh tests. On Sat, Nov 28, 2015 at 5:14 AM, Christoph Anton Mitterer wrote: > On Fri, 2015-11-27 at 20:00 +0100, Henk Slager wrote: >> As far as I can guess this is transfers between Seagate Archive 8TB >> SMR drives.

Re: slowness when cp respectively send/receiving on top of dm-crypt

On Sat, Nov 28, 2015 at 11:38 AM, Christoph Anton Mitterer wrote: > On Sat, 2015-11-28 at 11:34 -0700, Chris Murphy wrote: >> It sounds to me like maybe LUKS is configured to use an encryption >> algorithm that isn't subject to CPU optimized support, e.g. aes-xts >> on >>

Re: slowness when cp respectively send/receiving on top of dm-crypt

Henk Slager posted on Sat, 28 Nov 2015 19:37:31 +0100 as excerpted: > I did cp a 165G file to the SMR drive. The source had 130 extents and > just uncompressed btrfs raid10 fs, steadily 150+MB/s throughput. The fs > on the SMR disk is mounted like this: > /dev/mapper/dmcrypt_smr on /mnt/smr type

Re: slowness when cp respectively send/receiving on top of dm-crypt

> I'm just copying (via send/receive) a large filesystem (~7TB) from on > HDD over to another. > The devices are both connected via USB3, and each of the btrfs is on > top of dm-crypt. As far as I can guess this is transfers between Seagate Archive 8TB SMR drives. For max 250GB in new/clean state

slowness when cp respectively send/receiving on top of dm-crypt

Hey. Not sure if that's valuable input for the devs, but here's some vague real-world report about performance: I'm just copying (via send/receive) a large filesystem (~7TB) from on HDD over to another. The devices are both connected via USB3, and each of the btrfs is on top of dm-crypt. It's

Re: slowness when cp respectively send/receiving on top of dm-crypt

Hey. Send/receiving the master to the backup has finished just before... and now - not that I wouldn't trust btrfs, the hardware, etc. - I ran a complete diff --recursive --no-dereference over the snapshots on the two disks. The two btrfs are mounted ro (thus no write IO), there is not really

Re: slowness when cp respectively send/receiving on top of dm-crypt

On Fri, 2015-11-27 at 20:00 +0100, Henk Slager wrote: > As far as I can guess this is transfers between Seagate Archive 8TB > SMR drives. Yes it is,... and I though about SMR being the reason at first, too, but: - As far as I understood SMR, it shouldn't kick in when I do what is mostly streaming