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
>>> positiv
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 K
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)
> bloc
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 b
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
>> my laptop gets 1600MiB/s
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
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.
> Yes it is,... and I th
On Fri, Nov 27, 2015 at 9:14 PM, Christoph Anton Mitterer
wrote:
> - Bust most importantly,... if the reason was SMR, why should always
> when no IO happens dmcrypt_write be at basically full CPU.
It sounds to me like maybe LUKS is configured to use an encryption
algorithm that isn't subject to
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
any
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 d
> 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 y
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 al
12 matches
Mail list logo