Re: Copying between lzo compressed BtrFS's: de/re-compressing.

[Diagon <kernel.boxy@xoxy.net>]

On 01/17/2016 01:27 PM, Chris Murphy - lists@colorremedies.com wrote:
> On Sun, Jan 17, 2016 at 1:42 PM, Diagon <kernel.boxy@xoxy.net> wrote:
>> On 01/15/2016 04:25 AM, Filipe Manana wrote:
>>> On Fri, Jan 15, 2016 at 9:56 AM, Timofey Titovets <nefelim4ag@gmail.com> wrote:
>>
>>>> 2016-01-15 12:00 GMT+03:00 Diagon <kernel.boxy@xoxy.net>:
>>
>>>>> 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). 

Got it.

> 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.

Fantastic!  I could have actually used this on a new build by using the
installer to build into a new subvolume and then moving the files over.

I'll know next time.  Much appreciated.

/D