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 52EFCC433EF for ; Tue, 15 Feb 2022 21:51:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CBB106B007B; Tue, 15 Feb 2022 16:51:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C66FE6B007D; Tue, 15 Feb 2022 16:51:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B083D6B007E; Tue, 15 Feb 2022 16:51:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0215.hostedemail.com [216.40.44.215]) by kanga.kvack.org (Postfix) with ESMTP id A369E6B007B for ; Tue, 15 Feb 2022 16:51:18 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 62AC28249980 for ; Tue, 15 Feb 2022 21:51:18 +0000 (UTC) X-FDA: 79146360636.08.E444127 Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by imf03.hostedemail.com (Postfix) with ESMTP id B85392000C for ; Tue, 15 Feb 2022 21:51:17 +0000 (UTC) Received: by mail-pj1-f44.google.com with SMTP id v5-20020a17090a4ec500b001b8b702df57so4461665pjl.2 for ; Tue, 15 Feb 2022 13:51:17 -0800 (PST) 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:content-transfer-encoding; bh=UF22wzNFpm2IeXFXPkRt/7QTNpA2ZS3NNacg1G/BHTA=; b=aLkLiUl2q3+S6eeMXpypsrxoD5fjO9umu93awZL2f4DtK7iBq9t1st5HRP4P9rgAKQ vbbbxGJdWSs0YTXYqaQOXspsbJuV/Ut61sGZKXIhgZ+Ao1l2oLI2a3lopePAqvNg0AM/ kDMZ1kpGbiLtcFI4B2ZqtAbaAHRBWRiCwoQbOyqM63uY3euR9sdAmumj5oYMSCVi95Ns 1sW4wxDTlXLSh9B6p0n0D3UkJbjeDvFRKeSYt2Q+/kQzExnf7VeE2lpE7rMUEQZ5fScV u6euyIJCEvIB0kJrnAAehROqriwI5p8Dq4L2NbjbKWOUOEKsNVQpkAWi+LR6NKEvikDK GEWA== 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:content-transfer-encoding; bh=UF22wzNFpm2IeXFXPkRt/7QTNpA2ZS3NNacg1G/BHTA=; b=JfyBkPtMT7hPBqCAkMSwBNIVK6if+fRyBpRxh4OVhlSMfLI+Af9gHrgyAxaR3adBVG Qhw2pk19Xr9Ykgz5SdR32fdMdo6GFeqsnnkU4rop6jBGwzzDmP1/hp1tZONpOYJxILux Lp9SnXVCmXpSrjJFWjvB0v9XxKl7yuBTGO6s236sw/nuG90eLcZXDeRAsVUcXU3hzLNW Il7+OO+wKSEqwDaqOvbk5b6sWj5ys39XTASfuY3hkRuE4K8YOcODEN63c5CWGuALzHTR WKaqyDLey9mvpg93sj/WP3wzovx7+I8iDvjeWLXn9QxI4WyVNdErcZYJKxE7FLdsmbjn qVaA== X-Gm-Message-State: AOAM531QQxFeW51+o763n61SGqeyZ9LS/Ro7vQ4S7/vks+N46hgpu23q Qq7hKx058jq/V2AaLa3m6MkG9+5GsjP2Y0rK09ax/g== X-Google-Smtp-Source: ABdhPJwiWSTwvDiLHvEHx5jVlkEcfKkWS636fiMP5bezJwAkxTbJWDUQr5zyAmugPr7yn16pxbnRwJ5XVgTvcXGjjUQ= X-Received: by 2002:a17:902:b20a:: with SMTP id t10mr753705plr.132.1644961876547; Tue, 15 Feb 2022 13:51:16 -0800 (PST) MIME-Version: 1.0 References: <20220105181230.GC398655@magnolia> <20220105185626.GE398655@magnolia> <20220105224727.GG398655@magnolia> <20220105235407.GN656707@magnolia> <76f5ed28-2df9-890e-0674-3ef2f18e2c2f@fujitsu.com> <20220121022200.GG13563@magnolia> In-Reply-To: <20220121022200.GG13563@magnolia> From: Dan Williams Date: Tue, 15 Feb 2022 13:51:10 -0800 Message-ID: Subject: Re: [PATCH v9 02/10] dax: Introduce holder for dax_device To: "Darrick J. Wong" Cc: Shiyang Ruan , Christoph Hellwig , Linux Kernel Mailing List , linux-xfs , Linux NVDIMM , Linux MM , linux-fsdevel , david , Jane Chu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B85392000C X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b=aLkLiUl2; spf=none (imf03.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.216.44) 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: 3osj9mxybhqwetkix6g8gc51fhgghmxb X-Rspamd-Server: rspam03 X-HE-Tag: 1644961877-882590 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000014, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jan 20, 2022 at 6:22 PM Darrick J. Wong wrote: > > On Fri, Jan 21, 2022 at 09:26:52AM +0800, Shiyang Ruan wrote: > > > > > > =E5=9C=A8 2022/1/20 16:46, Christoph Hellwig =E5=86=99=E9=81=93: > > > On Wed, Jan 05, 2022 at 04:12:04PM -0800, Dan Williams wrote: > > > > We ended up with explicit callbacks after hch balked at a notifier > > > > call-chain, but I think we're back to that now. The partition mista= ke > > > > might be unfixable, but at least bdev_dax_pgoff() is dead. Notifier > > > > call chains have their own locking so, Ruan, this still does not ne= ed > > > > to touch dax_read_lock(). > > > > > > I think we have a few options here: > > > > > > (1) don't allow error notifications on partitions. And error retur= n from > > > the holder registration with proper error handling in the file > > > system would give us that > > Hm, so that means XFS can only support dax+pmem when there aren't > partitions in use? Ew. > > > > (2) extent the holder mechanism to cover a rangeo > > I don't think I was around for the part where "hch balked at a notifier > call chain" -- what were the objections there, specifically? I would > hope that pmem problems would be infrequent enough that the locking > contention (or rcu expiration) wouldn't be an issue...? > > > > (3) bite the bullet and create a new stacked dax_device for each > > > partition > > > > > > I think (1) is the best option for now. If people really do need > > > partitions we'll have to go for (3) > > > > Yes, I agree. I'm doing it the first way right now. > > > > I think that since we can use namespace to divide a big NVDIMM into mul= tiple > > pmems, partition on a pmem seems not so meaningful. > > I'll try to find out what will happen if pmem suddenly stops supporting > partitions... Finally catching up with this thread... Given that XFS already has the policy of disabling DAX rather than failing the mount in some cases, I think it is workable for XFS to fail a DAX mount if reflink is enabled on a partition. This should not regress anyone's current setup since the FS will not even mount with dax+reflink today. As to the specific concern about registering failure handlers for other purposes I expect that can be done by registering failure notification handlers on block devices, not dax devices. So it's not that pmem will suddenly stop supporting partitions, dax will simply never gain support for reflink in the presence of partitions.