Copying between lzo compressed BtrFS's: de/re-compressing.
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?
Thanks
/D
2016-01-15 12:00 GMT+03:00 Diagon <[email protected]>:
Quoted 3 lines
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
Signature · 2 lines
Have a nice day, Timofey.
Quoted 8 lines · Timofey Titovets
2016-01-15 12:00 GMT+03:00 Diagon <[email protected]>:
Quoted 3 lines
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.
Quoted 9 lines
--
Have a nice day,
Timofey.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 5 lines
Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
Thanks, Filipe ^_^
2016-01-15 15:25 GMT+03:00 Filipe Manana <[email protected]>:
Quoted 33 lines · Timofey Titovets
Quoted 8 lines
2016-01-15 12:00 GMT+03:00 Diagon <[email protected]>:
Quoted 3 lines
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 featureNo, 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.
Quoted 9 lines
--
Have a nice day,
Timofey.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html--
Filipe David Manana,"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
Signature · 2 lines
Have a nice day, Timofey.
Quoted 8 lines · Filipe Manana
Quoted 6 lines · Timofey Titovets
2016-01-15 12:00 GMT+03:00 Diagon <[email protected]>:
Quoted 3 lines
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?
Quoted 8 lines
Quoted 3 lines
If you just copy files, files will be decompressed while reading and recompressed while writing
For avoiding this, you must use send receive featureNo, 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.)
Quoted 2 lines
Quoted 2 lines
Have a nice day,
Timofey.
Thanks
/D.
Quoted 13 lines · Diagon
Quoted 12 lines · Filipe Manana
Quoted 9 lines · Timofey Titovets
2016-01-15 12:00 GMT+03:00 Diagon <[email protected]>:
Quoted 3 lines
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
Quoted 7 lines
Quoted 4 lines
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.
Signature · 1 line
Chris Murphy
Quoted 19 lines · On 01/17/2016 01:27 PM, Chris Murphy - [email protected] wrote:
Quoted 18 lines · Diagon
Quoted 16 lines · Filipe Manana
Quoted 9 lines · Timofey Titovets
2016-01-15 12:00 GMT+03:00 Diagon <[email protected]>:
Quoted 3 lines
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 featureNo, 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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 5 lines
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