Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1089478pxb; Thu, 19 Aug 2021 20:10:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJywwZfvWVzbnIm/pRa8wcHJuqnrt9OlSdpuW3xAX9pczZaKXmw3LeHbpC5zRllqIRkGK6GY X-Received: by 2002:a05:6e02:1c03:: with SMTP id l3mr428441ilh.219.1629429042165; Thu, 19 Aug 2021 20:10:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629429042; cv=none; d=google.com; s=arc-20160816; b=uCO5IKotvpMkSPx1ZW/bTAf3Rt/yzB600h/UcWcOm8CQ3u0Le2ZSzvm5LJ2PnZF+c8 wLKmMWG64DyLTUzmfRRqgpuclw+ADmfAGzG6m/0l1oQhUoWq79kUtCI1YDAb257g/Jdj p8NQLvX64wMJcB66uN3Sm//kZEklDT345qXd/jagOt8BAPFdiVe4pn1bkIBD5n/iAdAp 7A1ke6uwK9e+ZcJE1juRFmMSCcXKbKyblN39KwlmIeU43bSjdEScy1jKpNKyBuDWQ37i 97N9Kr0vzdHxo7/egecmNIaezF/tNjImhxiX020dxxs6J+wpe5nxlWrTYfE9HxrTpNuH lqRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=th+3o8zziVHjvxzUP987Ww05j4TcgD1JnSG4koxybv0=; b=DakoO6axSTKUmmTDN/mx3VweN1y0QvA9ECkKoQL2oFshwybRo5UCnm/3GPZIOlk7Cb B2JOMMD9vcnuN2stPLChN525JiOLZI4KIxPxKYzInEvueDrXA725Bwhe656KleNnRgM3 WV+UPTZbHlYqfg6J+rloU5yyLDT9Nvj+MTv33Rz8sBDb7PksLRwP0jl9g4C4OpDrHr3n ph5ZVhkC/VStTNN2tJPDTvC9CIPw/wGrbRGLIuKDBCeTm22KoyraG31jDn2WbIgtgUiy XUDkgT6NrYtnxRZ1+PZdHADxLqDm4UFI8UXD2RDhH4AIbB2aIKiUNlzX5d0iCP7olICP h0Ew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=q6wVy4gs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q10si5786592ilu.60.2021.08.19.20.10.30; Thu, 19 Aug 2021 20:10:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=q6wVy4gs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238070AbhHTDI6 (ORCPT + 99 others); Thu, 19 Aug 2021 23:08:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48554 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237933AbhHTDI5 (ORCPT ); Thu, 19 Aug 2021 23:08:57 -0400 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9787C061756 for ; Thu, 19 Aug 2021 20:08:20 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id u11-20020a17090adb4b00b00181668a56d6so50214pjx.5 for ; Thu, 19 Aug 2021 20:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=th+3o8zziVHjvxzUP987Ww05j4TcgD1JnSG4koxybv0=; b=q6wVy4gsAMeGwkQk1GUOlCv3RL83jjFdSVgzVK6FKAVlTxnluo0nxdXMv090oS+6v5 g/bsuD3TnVs6GjejENx6Ypc13QJi/TkgLHU9+HcG4DHRHbsowvEEqntPZXYalrUu+j31 syDAnCHyvx3HduCFB+iILfPCIv+IleAOlCNuCLhbaR1BW+2UQ0tOrUKFxEdC+UO92K1/ 4QLTyL7EAEUhfv9vEPkShzVSM6rjyvX4GxezOP/i3Yoj+vduXuzI5RGoQbgTNemm6050 3oyP1/6v7jPKCnfIP9AKLiBGwOOTQxTStdJIfOldCpt5V13LoApTXFCa0YTEXgvKOvuY g4MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=th+3o8zziVHjvxzUP987Ww05j4TcgD1JnSG4koxybv0=; b=ot7AuhzDLQ2UASQR/Wk7kkOpOwy6m6YiztX83lE8gqq6wB48rng7BiKE6mtq/vOlf0 9/I4NLpV1l4xxRyw+UoDo+Ug29AV7hWSaDueks1uW4swgtuMDCkc56i9BmZhEjDhJJOq BfVadyZsTG8M1xFbRALeb6tEICF8aB8h17gUC2T8nwdUuyx6o4HcQVuK2ixS9Mmsr+aI htB2NhOoawhENF9pGtrRDK8TQiKV3gz4jc9GKWqX/sjWALdn0JfEW7Xe6dE7BRvRrigf yRizbaYZX3nLcH+WlLRu/A2Hq1EglRmXtxg6tkLA40857YvdhlmchKQNtUhiUMAR9q0e bdDA== X-Gm-Message-State: AOAM532X0vOv/e8gek5T/VLC1b40wZMsJeQlGRc083Kht2qaasrtfsyH K+z2LKgHuoGhwKh4reIa917L+gPO9BV7NGFwEA2HDw== X-Received: by 2002:a17:902:e54e:b0:12d:cca1:2c1f with SMTP id n14-20020a170902e54e00b0012dcca12c1fmr14381234plf.79.1629428900343; Thu, 19 Aug 2021 20:08:20 -0700 (PDT) MIME-Version: 1.0 References: <20210816060359.1442450-1-ruansy.fnst@fujitsu.com> <20210816060359.1442450-9-ruansy.fnst@fujitsu.com> In-Reply-To: <20210816060359.1442450-9-ruansy.fnst@fujitsu.com> From: Dan Williams Date: Thu, 19 Aug 2021 20:08:09 -0700 Message-ID: Subject: Re: [PATCH v7 8/8] fs/xfs: Add dax dedupe support To: Shiyang Ruan Cc: "Darrick J. Wong" , Christoph Hellwig , linux-xfs , david , linux-fsdevel , Linux Kernel Mailing List , Linux NVDIMM , Goldwyn Rodrigues , Al Viro , Matthew Wilcox Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Aug 15, 2021 at 11:05 PM Shiyang Ruan wrote: > > Introduce xfs_mmaplock_two_inodes_and_break_dax_layout() for dax files > who are going to be deduped. After that, call compare range function > only when files are both DAX or not. > > Signed-off-by: Shiyang Ruan > Reviewed-by: Darrick J. Wong > --- > fs/xfs/xfs_file.c | 2 +- > fs/xfs/xfs_inode.c | 57 ++++++++++++++++++++++++++++++++++++++++++++ > fs/xfs/xfs_inode.h | 1 + > fs/xfs/xfs_reflink.c | 4 ++-- > 4 files changed, 61 insertions(+), 3 deletions(-) [..] > diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c > index 13e461cf2055..86c737c2baeb 100644 > --- a/fs/xfs/xfs_reflink.c > +++ b/fs/xfs/xfs_reflink.c > @@ -1327,8 +1327,8 @@ xfs_reflink_remap_prep( > if (XFS_IS_REALTIME_INODE(src) || XFS_IS_REALTIME_INODE(dest)) > goto out_unlock; > > - /* Don't share DAX file data for now. */ > - if (IS_DAX(inode_in) || IS_DAX(inode_out)) > + /* Don't share DAX file data with non-DAX file. */ > + if (IS_DAX(inode_in) != IS_DAX(inode_out)) > goto out_unlock; What if you have 2 DAX inodes sharing data and one is flipped to non-DAX? Does that operation need to first go undo all sharing?