GNU bug report logs - #23904
Btrfs clone support in copy operations

Previous Next

Full log

Message #14 received at 23904 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Dmitry Antipov <dmantipov <at> yandex.ru>, 23904 <at> debbugs.gnu.org
Cc: sbaugh <at> catern.com, Kieran Colford <kieran <at> kcolford.com>
Subject: Re: bug#23904: Btrfs clone support in copy operations
Date: Wed, 6 Jul 2016 13:48:26 +0200

[Message part 1 (text/plain, inline)]

On 07/06/2016 04:45 AM, Dmitry Antipov wrote:
> IMHO this should use FICLONERANGE in a loop where you can
> handle 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 (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.