Stefan Priebe - Profihost AG posted on Mon, 17 Oct 2016 08:50:37 +0200 as excerpted:
> 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 >>>>> [...] 204010946560 Oct 14 12:15 vm-279-disk-1.img >>>>> >>>>> target file after around 10 minutes: >>>>> # ls -la vm-279-disk-1.img.tmp >>>>> [...] 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? I flagged that as I read it, too, but... 200 KB extents average suggests it can't be compressed, because if it were they'd be 128 KB extents, not 200 KB. That's a difference of over half a million extents (128 KB would be ~1.5565 million extents, while just over a million are reported), too much to be rounding error, so the evidence doesn't support btrfs compression being the culprit. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
