At 10/17/2016 02:50 PM, Stefan Priebe - Profihost AG wrote:
Am 17.10.2016 um 03:50 schrieb Qu Wenruo:
At 10/17/2016 02:54 AM, Stefan Priebe - Profihost AG wrote:
Am 16.10.2016 um 00:37 schrieb Hans van Kranenburg:
Hi,
On 10/15/2016 10:49 PM, Stefan Priebe - Profihost AG wrote:
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
Thanks,
Qu
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
