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 X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76527C432BE for ; Fri, 20 Aug 2021 23:46:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 08E5F611AD for ; Fri, 20 Aug 2021 23:46:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 08E5F611AD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 6315D8D0001; Fri, 20 Aug 2021 19:46:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E1C66B0072; Fri, 20 Aug 2021 19:46:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D0848D0001; Fri, 20 Aug 2021 19:46:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0161.hostedemail.com [216.40.44.161]) by kanga.kvack.org (Postfix) with ESMTP id 2FE616B0071 for ; Fri, 20 Aug 2021 19:46:41 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B2D58182811C0 for ; Fri, 20 Aug 2021 23:46:40 +0000 (UTC) X-FDA: 78497096160.23.49C49F2 Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by imf05.hostedemail.com (Postfix) with ESMTP id 3584550773C4 for ; Fri, 20 Aug 2021 23:46:40 +0000 (UTC) Received: by mail-pg1-f176.google.com with SMTP id e7so10740208pgk.2 for ; Fri, 20 Aug 2021 16:46:39 -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=eHMEwcWn5S7G+chbvcpQTCNCdRCcbE/CWjRPjJXaV5I=; b=dV1qy1mgsEI4INkTjHHUKy2f7GSIBsf4O1+fXHWSy+kAEv3jYRCYAaMAoxshjnqkyG oT2A+bqzdhWPP7Nst6cJc+rRq8qjOqCAzweIkXIkoEgo8nuUUMoiRJVOkDK3YmorYY2a MiYIB0B/a9xDq85QpmZl/2OTACzF1vsdUrsmu7G3BBNzopmDSm3t3cTCYxalZF+EklbQ z/QBhrFGCRX/NdduCq4/gSDYTAIHTqZ63QqvdfDM9w8L08bZLCVJabVWF+5h1GcwWdBx g+Yx1heQOEc1eDGWC1flE3Y5YJQ9B8bHRxJIIM5h054uHHrScv9Gt6FUJTVHrhRhnuED x2EA== 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=eHMEwcWn5S7G+chbvcpQTCNCdRCcbE/CWjRPjJXaV5I=; b=my0JdGXNZty9BBsHpPjLYVtbD8SDaXmw3IzMwpizKzMbYKejp2D3+xdjpVX/SCPsJF FUpYj/hByynawNi0siQS3TP8/f/vLbDNcJKBsavSBIALEbZWAnmDEYODETOJoPIRa26D wE9vdpluaz5h/+dQdvuZXpwe9/xSZQEo87Tjsg/6igEG+Gu1jiKFr76+tRLgNxvURYNV D+Q3QLlSXdAOeyfutzlCxh1ToeIRS/5jXJGy54Sc6ZErCttWGbvKC8yfd3+/KZcqFVcz b3C9atj3IyUja/1TWnwTpSaoRNVrh0BFvvf4iIMJlHp+yuTDC9wVr+bYVlX8KFHQc7ty S6wQ== X-Gm-Message-State: AOAM53142hstjXlONBb2XT0LKypYSPjK+SO9C9BPXT2qKVrT5KOkVQbH hPWHF7v+0aEJbMnZXpR8J6KL8AGQFB0k4KkehV74RA== X-Google-Smtp-Source: ABdhPJzS5HGT6xJgqFrmEph3uz/ZG7OFdXOcKr3T36oL70Xxr6i57XBJUHqsj1rzOh9dfprsZA/boIS7GPxjc7UyUjw= X-Received: by 2002:a62:3342:0:b029:3b7:6395:a93 with SMTP id z63-20020a6233420000b02903b763950a93mr21855818pfz.71.1629503199185; Fri, 20 Aug 2021 16:46:39 -0700 (PDT) MIME-Version: 1.0 References: <20210730100158.3117319-1-ruansy.fnst@fujitsu.com> <20210730100158.3117319-8-ruansy.fnst@fujitsu.com> In-Reply-To: <20210730100158.3117319-8-ruansy.fnst@fujitsu.com> From: Dan Williams Date: Fri, 20 Aug 2021 16:46:27 -0700 Message-ID: Subject: Re: [PATCH RESEND v6 7/9] dm: Introduce ->rmap() to find bdev offset To: Shiyang Ruan Cc: Linux Kernel Mailing List , linux-xfs , Linux NVDIMM , Linux MM , linux-fsdevel , device-mapper development , "Darrick J. Wong" , david , Christoph Hellwig , Alasdair Kergon , Mike Snitzer Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=intel-com.20150623.gappssmtp.com header.s=20150623 header.b=dV1qy1mg; spf=none (imf05.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.215.176) smtp.mailfrom=dan.j.williams@intel.com; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none) X-Stat-Signature: 1brkyzytru89cm3bx4eddosmj8wzye9e X-Rspamd-Queue-Id: 3584550773C4 X-Rspamd-Server: rspam04 X-HE-Tag: 1629503200-227738 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, Jul 30, 2021 at 3:02 AM Shiyang Ruan wrote: > > Pmem device could be a target of mapped device. In order to find out > the global location on a mapped device, we introduce this to translate > offset from target device to mapped device. > > Currently, we implement it on linear target, which is easy to do the > translation. Other targets will be supported in the future. However, > some targets may not support it because of the non-linear mapping. > > Signed-off-by: Shiyang Ruan > --- > block/genhd.c | 56 +++++++++++++++++++++++++++++++++++ > drivers/md/dm-linear.c | 20 +++++++++++++ > include/linux/device-mapper.h | 5 ++++ > include/linux/genhd.h | 1 + > 4 files changed, 82 insertions(+) This might be where dax-device support needs to part ways with the block layer. As Christoph has mentioned before the long term goal for dax-devices (direct mapped byte-addressable media) is to have filesystems mount on them directly and abandon block-layer entanglements. This patch goes the opposite direct and adds more block layer infrastructure to support a dax-device need. Now, I'm not opposed to this moving forward, but I'm not sure block and DM maintainers will be excited about this additional maintenance burden. At the same time a lot of effort has been poured into dax-reflink and I want that support to move forward. So, my proposal while we figure out what to do about device-mapper rmap is to have fs_dax_register_holder() fail on device-mapper dax-devices until we get wider agreement amongst all involved that this is an additional burden worth carrying. In the meantime XFS on PMEM will see fs_dax_register_holder() succeed and DAX reflink support can be gated on whether the dax-device allowed the notify failure handler to be registered. Now, there may be room to allow reflink on device-mapper-dax for CONFIG_MEMORY_FAILURE=n builds, but that would collide with future work to use notify_failure for more than memory_failure, but also NVDIMM_REVALIDATE_POISON, and surprise memory-device-remove events. The code in this patch looks ok to me, just not the direction the dax-device layer was looking to go. It might be time to revive the discussions around support for concatenation and striping in the pmem driver itself, especially as the CXL label specification is already adding support for physically discontiguous namespaces. At a minimum if the patch set is organized to support XFS-reflink on PMEM-DAX and later XFS-reflink on DM-DAX some progress can be made without waiting for the whole set to be accepted.