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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 2218BC3F2D2 for ; Fri, 28 Feb 2020 16:27:10 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ECC07246A0 for ; Fri, 28 Feb 2020 16:27:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="bukCJoLW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ECC07246A0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 71C6710FC33FA; Fri, 28 Feb 2020 08:28:01 -0800 (PST) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::343; helo=mail-ot1-x343.google.com; envelope-from=dan.j.williams@intel.com; receiver= Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CBF1D10078091 for ; Fri, 28 Feb 2020 08:27:58 -0800 (PST) Received: by mail-ot1-x343.google.com with SMTP id j16so3142422otl.1 for ; Fri, 28 Feb 2020 08:27:06 -0800 (PST) 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=akPX/Le0d2EiQmbAvQA94ZihJyml6bsfezTs1xR+aWI=; b=bukCJoLWpFuG4kP9cdoMOAtCcw6mtymH0738+Cr/dDuwu2ERG+5ejt9RigalXEkE32 ogfqK+z82ZNA/pFMw3Cu3QBXiOahIJfVWFrSmMRHS/dIAbAT8wPAeq/8mbKwzGbs87el vvNtku4b4DFwyy2BaTPexmQz08UfnrFhesbV0UQsYbBzUnOuocPHTK+SKO6ylLGpWw9h Q59r+4Gy7GuB89UgLq2iltRlyb851aKavJ+mzpWZYrohrqmC2lFhYZEOIfwymFvKJz7g fsLSmh+43Inz1Qqeyiq/bD/wEsiC3YMv33ThnmFvBY8AOX+YrlWks1wsVEeDIpKM5wou FpPA== 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=akPX/Le0d2EiQmbAvQA94ZihJyml6bsfezTs1xR+aWI=; b=Ek3/SnSa/CBuKDdpiu5OHpxVAqYizski9TCDeBzuXAXfzNSyYVRBa2zCrKP91PMjfx sOMo351qw1L3CqRYRUK1hNHLlWiLOI0GO8Fs5Mu+k433jz7547CDYY5h/880C/xGKzDM 4LkrzkNzVKZWKKyenlPBBBzAWfe0C4w1XGflZ5WQHh3W2PvzPxfXvqNVFGdY/TtR/4ly VgpUYcsLY+AyNLudSryI4ErD/ENz0ux3KZIzHegEX9icGwzxQ+3uHVkPw5ZiptF3f7Sk 24c0T+1fBncnC7JxipeLHZFpiO0z3wGaG5L2lNbSFg9cS1Ffl6rtv+EJbnl0XUOuMppb FUAA== X-Gm-Message-State: APjAAAU5z54qNNtAWRuLmL4GvOqTWEDwJJ77SjE67s5CIgYWRnwUo7fx SuMJ28fEP/apnGirOV+jYeVBF5m9AF8u0YhlCUI8Dw== X-Google-Smtp-Source: APXvYqxPIfQgCnD3v9HTx5cFPLUInp7b+fRgEsmGH/hBamVfDcdplRO8p87KJZr4ZSNSQycJp3mYOu5p6SffilbLu3s= X-Received: by 2002:a9d:6c9:: with SMTP id 67mr4103721otx.363.1582907225590; Fri, 28 Feb 2020 08:27:05 -0800 (PST) MIME-Version: 1.0 References: <20200220215707.GC10816@redhat.com> <20200221201759.GF25974@redhat.com> <20200223230330.GE10737@dread.disaster.area> <20200224153844.GB14651@redhat.com> <20200227030248.GG10737@dread.disaster.area> <20200228013054.GO10737@dread.disaster.area> <20200228140508.GA2987@infradead.org> In-Reply-To: <20200228140508.GA2987@infradead.org> From: Dan Williams Date: Fri, 28 Feb 2020 08:26:54 -0800 Message-ID: Subject: Re: [PATCH v5 2/8] drivers/pmem: Allow pmem_clear_poison() to accept arbitrary offset and len To: Christoph Hellwig Message-ID-Hash: GAD7S7WJHZMTVOIQL6GGRKU5KSLJACT4 X-Message-ID-Hash: GAD7S7WJHZMTVOIQL6GGRKU5KSLJACT4 X-MailFrom: dan.j.williams@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: Dave Chinner , linux-fsdevel , linux-nvdimm , device-mapper development X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, Feb 28, 2020 at 6:05 AM Christoph Hellwig wrote: > > On Thu, Feb 27, 2020 at 07:28:41PM -0800, Dan Williams wrote: > > "don't perform generic memory-error-handling, there's an fs that owns > > this daxdev and wants to disposition errors". The fs/dax.c > > infrastructure that sets up ->index and ->mapping would still need to > > be there for ext4 until its ready to take on the same responsibility. > > Last I checked the ext4 reverse mapping implementation was not as > > capable as XFS. This goes back to why the initial design avoided > > relying on not universally available / stable reverse-mapping > > facilities and opted for extending the generic mm/memory-failure.c > > implementation. > > The important but is that we stop using ->index and ->mapping when XFS > is used as that enables using DAX+reflinks, which actually is the most > requested DAX feature on XFS (way more than silly runtime flag switches > for example). Understood. To be clear the plan we are marching to is knock down all the known objections to the removal of the "experimental" designation. reflink is on that list and so is per-file dax. The thought was that pef-file dax was a nearer term goal than reflink. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org 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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 3A838C3F2D2 for ; Fri, 28 Feb 2020 16:27:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0A7482469C for ; Fri, 28 Feb 2020 16:27:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="bukCJoLW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726063AbgB1Q1G (ORCPT ); Fri, 28 Feb 2020 11:27:06 -0500 Received: from mail-ot1-f67.google.com ([209.85.210.67]:44859 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725730AbgB1Q1G (ORCPT ); Fri, 28 Feb 2020 11:27:06 -0500 Received: by mail-ot1-f67.google.com with SMTP id h9so3078910otj.11 for ; Fri, 28 Feb 2020 08:27:06 -0800 (PST) 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=akPX/Le0d2EiQmbAvQA94ZihJyml6bsfezTs1xR+aWI=; b=bukCJoLWpFuG4kP9cdoMOAtCcw6mtymH0738+Cr/dDuwu2ERG+5ejt9RigalXEkE32 ogfqK+z82ZNA/pFMw3Cu3QBXiOahIJfVWFrSmMRHS/dIAbAT8wPAeq/8mbKwzGbs87el vvNtku4b4DFwyy2BaTPexmQz08UfnrFhesbV0UQsYbBzUnOuocPHTK+SKO6ylLGpWw9h Q59r+4Gy7GuB89UgLq2iltRlyb851aKavJ+mzpWZYrohrqmC2lFhYZEOIfwymFvKJz7g fsLSmh+43Inz1Qqeyiq/bD/wEsiC3YMv33ThnmFvBY8AOX+YrlWks1wsVEeDIpKM5wou FpPA== 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=akPX/Le0d2EiQmbAvQA94ZihJyml6bsfezTs1xR+aWI=; b=Ju0OdVHB5ZTdnbjUdeHocHOZTEMY3jcFHatSgNQjgPQrJybLcM+sKX6bGTuaF0d8ZR /Ix8QjVz7VpeepPojNPOK/BTJ7xW8JtvJ8lzhIVEOdZx6MOTWPrLXBt/XwcvN4E15RWB BPESI+P5XuXf7RpUnB2QnrukSTvenn0FmBW54E4MWT8Fwkm1fMXA6wYgY/KqgBXxDQN3 sH6HDDecjTy6H1Dapt9669InunfP802jqbNDyvdyW7Q9O2da24h78CxVp29yEmwD3k8j E7MBFO+XixhUb+fJpYBb7MJQxI3L5YFe0plmPPIq0m1qL3NhhBsfAz3v30cjf0cZNEJC CKEA== X-Gm-Message-State: APjAAAWx6kWmK0rRbC0IbfVmKwCnzSpQLq9ZljpB5VCubfAA8RdO+G3m wVk727QjLqePbGw2WHR0ufH3Q3KbCYErRAnFFOGlNsAs X-Google-Smtp-Source: APXvYqxPIfQgCnD3v9HTx5cFPLUInp7b+fRgEsmGH/hBamVfDcdplRO8p87KJZr4ZSNSQycJp3mYOu5p6SffilbLu3s= X-Received: by 2002:a9d:6c9:: with SMTP id 67mr4103721otx.363.1582907225590; Fri, 28 Feb 2020 08:27:05 -0800 (PST) MIME-Version: 1.0 References: <20200220215707.GC10816@redhat.com> <20200221201759.GF25974@redhat.com> <20200223230330.GE10737@dread.disaster.area> <20200224153844.GB14651@redhat.com> <20200227030248.GG10737@dread.disaster.area> <20200228013054.GO10737@dread.disaster.area> <20200228140508.GA2987@infradead.org> In-Reply-To: <20200228140508.GA2987@infradead.org> From: Dan Williams Date: Fri, 28 Feb 2020 08:26:54 -0800 Message-ID: Subject: Re: [PATCH v5 2/8] drivers/pmem: Allow pmem_clear_poison() to accept arbitrary offset and len To: Christoph Hellwig Cc: Dave Chinner , Vivek Goyal , Jeff Moyer , linux-fsdevel , linux-nvdimm , device-mapper development Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Feb 28, 2020 at 6:05 AM Christoph Hellwig wrote: > > On Thu, Feb 27, 2020 at 07:28:41PM -0800, Dan Williams wrote: > > "don't perform generic memory-error-handling, there's an fs that owns > > this daxdev and wants to disposition errors". The fs/dax.c > > infrastructure that sets up ->index and ->mapping would still need to > > be there for ext4 until its ready to take on the same responsibility. > > Last I checked the ext4 reverse mapping implementation was not as > > capable as XFS. This goes back to why the initial design avoided > > relying on not universally available / stable reverse-mapping > > facilities and opted for extending the generic mm/memory-failure.c > > implementation. > > The important but is that we stop using ->index and ->mapping when XFS > is used as that enables using DAX+reflinks, which actually is the most > requested DAX feature on XFS (way more than silly runtime flag switches > for example). Understood. To be clear the plan we are marching to is knock down all the known objections to the removal of the "experimental" designation. reflink is on that list and so is per-file dax. The thought was that pef-file dax was a nearer term goal than reflink.