From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f171.google.com ([209.85.213.171]:33880 "EHLO mail-ig0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752554AbcAQV1x (ORCPT ); Sun, 17 Jan 2016 16:27:53 -0500 Received: by mail-ig0-f171.google.com with SMTP id ik10so44276979igb.1 for ; Sun, 17 Jan 2016 13:27:52 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <569BFCB1.2000107@xoxy.net> References: <5698B534.4040202@xoxy.net> <569BFCB1.2000107@xoxy.net> Date: Sun, 17 Jan 2016 14:27:52 -0700 Message-ID: Subject: Re: Copying between lzo compressed BtrFS's: de/re-compressing. From: Chris Murphy To: Diagon Cc: linux-btrfs Content-Type: text/plain; charset=UTF-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Sun, Jan 17, 2016 at 1:42 PM, Diagon wrote: > On 01/15/2016 04:25 AM, Filipe Manana wrote: >> On Fri, Jan 15, 2016 at 9:56 AM, Timofey Titovets wrote: > >>> 2016-01-15 12:00 GMT+03:00 Diagon : > >>>> I'm copying a large number of files between two lzo compressed BtrFS >>>> filesystems on different drives mounted on the same machine. It appears >>>> that the files are being de/re-compressed. Is there a way avoid this? >>> >>> If you just copy files, files will be decompressed while reading and >>> recompressed while writing >>> For avoiding this, you must use send receive feature >> >> No, send/receive does not avoid decompression on the send side nor >> re-compression at the receiving side. The receiving side writes the >> data from a send stream, which is uncompressed, to the destination >> filesystem using standard system calls like write/pwrite. > > So, just to spell it out, I understand that de/re-compression is > unavoidable? (And I'll post that to my stackexchange question.) It's unavoidable when replicating data across file systems (send/receive, rsync, cp). It's avoidable if you use a seed device, add a new device, then delete the seed. While the volume UUID changes with this process, the duplicate volume is essentially the same as the source (the process copies chunks), which means the chunk profile is also preserved. -- Chris Murphy