From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C77E0C433F5 for ; Sat, 23 Apr 2022 17:33:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E3ADA6B0074; Sat, 23 Apr 2022 13:33:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DC3956B0075; Sat, 23 Apr 2022 13:33:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C3D026B0078; Sat, 23 Apr 2022 13:33:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id AF9D66B0074 for ; Sat, 23 Apr 2022 13:33:01 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7121C61911 for ; Sat, 23 Apr 2022 17:33:01 +0000 (UTC) X-FDA: 79388839362.25.C88B393 Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by imf03.hostedemail.com (Postfix) with ESMTP id 6794B20019 for ; Sat, 23 Apr 2022 17:32:58 +0000 (UTC) Received: by mail-pg1-f174.google.com with SMTP id 15so1553941pgf.4 for ; Sat, 23 Apr 2022 10:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xxYgAVRvbeskBRCc62b6dd1b3P0m/iQAjdEflJjZwEw=; b=cIGzVuvaHPW/VLTUuGNP05j8jEVx31lmj/3qbzCRsPPrbTPeSt32R9NgmplRr+LV2v TPG/LcGufNFw0M7teCiF+6fVAYn4/IZUkzhvU151c+DtN5zNP6ijWWFEX0r7a0X7hpZ6 xO3b46N9BlD5HOH/6KjSBgqpCWBJDeBsMQZmm79J4gye6fRcxGTlCl4dKaFf6y1mAURp E5R7bt7AOI4nxW4Mui2PMh/dI9vZ6rNafeuVBGnANyufcFvtdgr6zL9cseyBu2DWlLef OiFipnPqxqKTZqc5cVuZn5+/7HX/WRUNoR6ULhHbqgV/g2kNVB4EiarR81JxPDgXZFsx xVNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xxYgAVRvbeskBRCc62b6dd1b3P0m/iQAjdEflJjZwEw=; b=d9Q+Aceeyri++C+KY10zuXdRoYJv/4Cy9wg4/zSHeRU4vuc6glRrj6mGN734DZwDIg QUGqlLX80PuKDEbsEoDQBZ7phumbYx/TxfWV+S8SaqjZKe2GKxAmR07iLjL6H2ao6RLq z4QJjbvQtLgrGa8sM13fvkT5Cid2xMycQ0JgdPNVVvYRIs3L3dCHm4oWJTO8NiqpAR9y jg/TsLdUR+F1w1hHVeawcqhLf0/4osHpckxHaSynL+3wGQXttvXbnFD3sikb0thkpeND EOx6kPDkSMr+gtklu/K4AVAvqPT6LV60byVmNFIoBZ+Cn7woaMgPyIAtvmrmVgRduIff cxbQ== X-Gm-Message-State: AOAM532rHGL1NE/07N3Jbag5gnzxSWfQccbfSWdma8wNdHoN5HX3fWwv LxYOr5iU9RVtGCj47EQysz64ZPegYQU1wavaSVy83A== X-Google-Smtp-Source: ABdhPJy0mhTUMjh9InWAjD5l2gEPa+UaJvVCIFLNzGQ3RNZPm0s50yYnG9o8IIvsa9ZqP9/kYJI8dbG4WyP4ubzay9s= X-Received: by 2002:a05:6a02:283:b0:342:703e:1434 with SMTP id bk3-20020a056a02028300b00342703e1434mr8647836pgb.74.1650735179515; Sat, 23 Apr 2022 10:32:59 -0700 (PDT) MIME-Version: 1.0 References: <20220419045045.1664996-1-ruansy.fnst@fujitsu.com> <20220421012045.GR1544202@dread.disaster.area> <86cb0ada-208c-02de-dbc9-53c6014892c3@fujitsu.com> <20220421043502.GS1544202@dread.disaster.area> <20220421074653.GT1544202@dread.disaster.area> <20220423000121.GH1544202@dread.disaster.area> In-Reply-To: <20220423000121.GH1544202@dread.disaster.area> From: Dan Williams Date: Sat, 23 Apr 2022 10:32:48 -0700 Message-ID: Subject: Re: [PATCH v13 0/7] fsdax: introduce fs query to support reflink To: Dave Chinner Cc: Christoph Hellwig , Shiyang Ruan , Linux Kernel Mailing List , linux-xfs , Linux NVDIMM , Linux MM , linux-fsdevel , "Darrick J. Wong" , Jane Chu , Andrew Morton , Naoya Horiguchi Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 8mzcyn3djxbfafnt8dk6baza388mcz5h X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 6794B20019 X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b=cIGzVuva; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none); spf=none (imf03.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.215.174) smtp.mailfrom=dan.j.williams@intel.com X-HE-Tag: 1650735178-519304 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Apr 22, 2022 at 5:02 PM Dave Chinner wrote: > > On Fri, Apr 22, 2022 at 02:27:32PM -0700, Dan Williams wrote: > > On Thu, Apr 21, 2022 at 12:47 AM Dave Chinner wrote: > > > > > > On Wed, Apr 20, 2022 at 10:54:59PM -0700, Christoph Hellwig wrote: > > > > On Thu, Apr 21, 2022 at 02:35:02PM +1000, Dave Chinner wrote: > > > > > Sure, I'm not a maintainer and just the stand-in patch shepherd for > > > > > a single release. However, being unable to cleanly merge code we > > > > > need integrated into our local subsystem tree for integration > > > > > testing because a patch dependency with another subsystem won't gain > > > > > a stable commit ID until the next merge window is .... distinctly > > > > > suboptimal. > > > > > > > > Yes. Which is why we've taken a lot of mm patchs through other trees, > > > > sometimes specilly crafted for that. So I guess in this case we'll > > > > just need to take non-trivial dependencies into the XFS tree, and just > > > > deal with small merge conflicts for the trivial ones. > > > > > > OK. As Naoyo has pointed out, the first dependency/conflict Ruan has > > > listed looks trivial to resolve. > > > > > > The second dependency, OTOH, is on a new function added in the patch > > > pointed to. That said, at first glance it looks to be independent of > > > the first two patches in that series so I might just be able to pull > > > that one patch in and have that leave us with a working > > > fsdax+reflink tree. > > > > > > Regardless, I'll wait to see how much work the updated XFS/DAX > > > reflink enablement patchset still requires when Ruan posts it before > > > deciding what to do here. If it isn't going to be a merge > > > candidate, what to do with this patchset is moot because there's > > > little to test without reflink enabled... > > > > I do have a use case for this work absent the reflink work. Recall we > > had a conversation about how to communicate "dax-device has been > > ripped away from the fs" events and we ended up on the idea of reusing > > ->notify_failure(), but with the device's entire logical address range > > as the notification span. That will let me unwind and delete the > > PTE_DEVMAP infrastructure for taking extra device references to hold > > off device-removal. Instead ->notify_failure() arranges for all active > > DAX mappings to be invalidated and allow the removal to proceed > > especially since physical removal does not care about software pins. > > Sure. My point is that if the reflink enablement isn't ready to go, > then from an XFS POV none of this matters in this cycle and we can > just leave the dependencies to commit via Andrew's tree. Hence by > the time we get to the reflink enablement all the prior dependencies > will have been merged and have stable commit IDs, and we can just > stage this series and the reflink enablement as we normally would in > the next cycle. > > However, if we don't get the XFS reflink dax enablement sorted out > in the next week or two, then we don't need this patchset in this > cycle. Hence if you still need this patchset for other code you need > to merge in this cycle, then you're the poor schmuck that has to run > the mm-tree conflict guantlet to get a stable commit ID for the > dependent patches in this cycle, not me.... Yup. Let's give it another week or so to see if the reflink rebase materializes and go from there.