Re: speed up cp --reflink=always

At 10/17/2016 02:50 PM, Stefan Priebe - Profihost AG wrote:

Am 17.10.2016 um 03:50 schrieb Qu Wenruo:

quoted

At 10/17/2016 02:54 AM, Stefan Priebe - Profihost AG wrote:

quoted

Am 16.10.2016 um 00:37 schrieb Hans van Kranenburg:

quoted

Hi,

On 10/15/2016 10:49 PM, Stefan Priebe - Profihost AG wrote:

quoted

cp --reflink=always takes sometimes very long. (i.e. 25-35 minutes)

An example:

source file:
# ls -la vm-279-disk-1.img
-rw-r--r-- 1 root root 204010946560 Oct 14 12:15 vm-279-disk-1.img

target file after around 10 minutes:
# ls -la vm-279-disk-1.img.tmp
-rw-r--r-- 1 root root 65022328832 Oct 15 22:13 vm-279-disk-1.img.tmp

Two quick thoughts:
1. How many extents does this img have?

filefrag says:
1011508 extents found

Too many fragments.
Average extent size is only about 200K.
Quite common for VM images, if not setting no copy-on-write (C) attr.

Normally it's not a good idea to put VM images into btrfs without any
tuning.

Those are backups just written sequentially once. As far as i know the
extent size is hardcoded to 128k for compression. Isn't it?

Stefan

Just as Duncan said, for compress, its extent size is limited to 128K, 
unless you prealloc the file, sequence write is not possible to create 
extent larger than 128K.

Thanks,
Qu

quoted

Thanks,
Qu

quoted

quoted

2. Is this an XY problem? Why not just put the img in a subvolume and
snapshot that?

Sorry what's XY problem?

Implementing cp reflink was easier - as the original code was based on
XFS. But shouldn't be cp reflink / clone a file be nearly identical to a
snapshot? Just creating refs to the extents?

Greets,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html