Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938628AbcKXMDn (ORCPT ); Thu, 24 Nov 2016 07:03:43 -0500 Received: from mail-oi0-f44.google.com ([209.85.218.44]:33658 "EHLO mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936577AbcKXMDl (ORCPT ); Thu, 24 Nov 2016 07:03:41 -0500 MIME-Version: 1.0 X-Originating-IP: [217.173.44.24] In-Reply-To: References: <1479984944-1017-1-git-send-email-mszeredi@redhat.com> <1479984944-1017-6-git-send-email-mszeredi@redhat.com> From: Miklos Szeredi Date: Thu, 24 Nov 2016 13:03:40 +0100 Message-ID: Subject: Re: [PATCH 4/7] ovl: add infrastructure for intercepting file ops To: Amir Goldstein Cc: Miklos Szeredi , "linux-unionfs@vger.kernel.org" , linux-fsdevel , linux-kernel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 979 Lines: 24 On Thu, Nov 24, 2016 at 12:52 PM, Amir Goldstein wrote: > On Thu, Nov 24, 2016 at 12:55 PM, Miklos Szeredi wrote: >> + /* >> + * These should be intercepted, but they are very unlikely to be >> + * a problem in practice. Leave them alone for now. > > It could also be handled in vfs helpers. > Since these ops all start with establishing that src and dest are on > the same sb, > then the cost of copy up of src is the cost of clone_file_range from > lower to upper, > so it is probably worth to copy up src and leave those fops alone. > >> + */ >> + ofop->fops.copy_file_range = orig->copy_file_range; >> + ofop->fops.clone_file_range = orig->clone_file_range; >> + ofop->fops.dedupe_file_range = orig->dedupe_file_range; Not sure I understand. Why should we copy up src? Copy up is the problem not the solution. Thanks, Miklos