From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from verein.lst.de ([213.95.11.211]:58730 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753904AbcK2Iz2 (ORCPT ); Tue, 29 Nov 2016 03:55:28 -0500 Date: Tue, 29 Nov 2016 09:55:25 +0100 From: Christoph Hellwig To: Amir Goldstein Cc: Christoph Hellwig , "Darrick J. Wong" , Al Viro , Anna.Schumaker@netapp.com, linux-fsdevel Subject: Re: [PATCH] fs: try to clone files first in vfs_copy_file_range Message-ID: <20161129085525.GA6024@lst.de> References: <1480063201-17906-1-git-send-email-hch@lst.de> <1480063201-17906-2-git-send-email-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: [fullquote removed, please get your email etiquette right or I'll stop responding] > For fs that support both copy and clone, I am not convinced that it up to > VFS to take that decision for the application. We had that discussion many times. Yes, the system can decide it, as the application does not see the difference. > If application 'chose' copy over clone maybe it had a reason. Yes, because it's lazy and simply doesn't give a f**k how the data is copied. Clone provides much stronger guarantees, but if you don't need them you'll just use call that will always work. > I suggest to move this to 'clone fallback' after copy_file_range and before > do_splice_direct. That won't do the right thing for the NFS case. > A hypothetical case why copy_range implementation would be preferred > by an application that runs over specific hypothetical fs - copy_file_range > can be more easily implemented as a killable copy loop, returning the length > that was copy before interrupted by a signal. Clone is a fast metadata operation and is finished before you even had a chance to kill it.