On 10/16/2016 08:54 PM, Stefan Priebe - Profihost AG wrote: > Am 16.10.2016 um 00:37 schrieb Hans van Kranenburg: >> 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 To cp --reflink this, the filesystem needs to create a million new EXTENT_DATA objects for the new file, which point all parts of the new file to all the little same parts of the old file, and probably also needs to update a million EXTENT_DATA objects in the btrees to add a second backreference back to the new file. >> 2. Is this an XY problem? Why not just put the img in a subvolume and >> snapshot that? > > Sorry what's XY problem? It means that I suspected that your actual goal is not spending time to work on optimizing how cp --reflink works, but that you just want to use the quickest way to have a clone of the file. An XY problem is when someone has problem X, then thinks about solution Y to solve it, then runs into a problem/limitation/whatever when trying Y and asks help with that actual problem when doing Y while there might in the end be a better solution to get X done. > 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? Snapshotting a subvolume only has to write a cowed copy of the top-level information of the subvolume filesystem tree, and leaves the extent tree alone. It doesn't have to do 2 million different things. \o/ -- Hans van Kranenburg -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
