|
From: | Paul Eggert |
Subject: | bug#23904: Btrfs clone support in copy operations |
Date: | Wed, 6 Jul 2016 13:48:26 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 |
On 07/06/2016 04:45 AM, Dmitry Antipov wrote:
IMHO this should use FICLONERANGE in a loop where you canhandle errors and use process_pending_signals as usual.
Thanks, that suggestion should resolve the FIXME about how FICLONE behaves when the output file is already larger than the input. However, what should the clone chunk size be,each time through the loop? I don't use btrfs so I don't know what a good size would be.
A downside of the suggestion is that the file copy won't be atomic. However, the existing code isn't atomic, so this is nothing new.
Revised patch attached. Basically untested, since I don't use any file systems that support FIOCLONERANGE. The patch still has FIXMEs for what happens if the FIOCLONERANGE ioctl is interrupted by a signal, and for a good clone chunk size (the patch guesses 1 GiB).
0001-copy-file-now-uses-GNU-Linux-file-cloning.patch
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |