From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:34758 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1030752AbeGARor (ORCPT ); Sun, 1 Jul 2018 13:44:47 -0400 Date: Sun, 1 Jul 2018 12:44:43 -0500 From: Goldwyn Rodrigues To: Dave Chinner Cc: Steve French , linux-fsdevel Subject: Re: Copy tools on Linux Message-ID: <20180701174443.6lrpuurx5stsyvja@merlin> References: <20180701001005.GR19934@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180701001005.GR19934@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 07-01 10:10, Dave Chinner wrote: > On Fri, Jun 29, 2018 at 09:37:27PM -0500, Steve French wrote: > > I have been looking at i/o patterns from various copy tools on Linux, > > and it is pretty discouraging - I am hoping that I am forgetting an > > important one that someone can point me to ... > > > > Some general problems: > > 1) if source and target on the same file system it would be nice to > > call the copy_file_range syscall (AFAIK only test tools call that), > > although in some cases at least cp can do it for --reflink > > copy_file_range() should be made to do the right thing in as many > scnearios as we can document, and then switch userspace over to use > it at all times. Aggregate all the knowledge in one place, where we > know what the filesystem implementations are and can get hints to do > the right thing. We have discussed this earlier in https://www.spinics.net/lists/linux-fsdevel/msg125401.html and Christoph suggested that there is no point adding new flags for holes. Do you have a different opinion? The same is with coreutils maintainer where he suggested adding flags to perform everything with respect to holes in the kernel. -- Goldwyn