From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5945C2C81 for ; Fri, 22 Oct 2021 05:38:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=joQSPE1jf42K9iGwtLp9ug4KvVxpkMDtCEtS/1k1vQs=; b=jpz74NF63z9Xx79gxcWJoLwz/A piNaP7v1tEooFSBcu8kxM7mBbUWzsoeD+UW7lVE73ZJdXIJuxYCJuwJ78e6E+6QmPWP/KmL4EeqXS 2slRXyqI/CVBgh8MCxe6+Or75SfRoVW/Jc3zfBEfXmxwpwol+L0R7CHTU9bEfc3GETUBSG4KeZ0ii B77KRbiJ3NS6xTy8bVDD2B/ujpplso5cB9C1Ze6Mai377gQ59FDIb6DJ4Qlid9ICuLCmRbDawEUTE Rcd49rL8fcfyxLPtVCZTzQPPUP2TxjFptZTRfCg3eePEEWSyM6+BRXrDk4Q+c7E8boGbHY1+rVcI6 C3yjGJkw==; Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mdnFg-009lbb-Bd; Fri, 22 Oct 2021 05:38:00 +0000 Date: Thu, 21 Oct 2021 22:38:00 -0700 From: Christoph Hellwig To: "Darrick J. Wong" Cc: Jane Chu , Christoph Hellwig , "david@fromorbit.com" , "dan.j.williams@intel.com" , "vishal.l.verma@intel.com" , "dave.jiang@intel.com" , "agk@redhat.com" , "snitzer@redhat.com" , "dm-devel@redhat.com" , "ira.weiny@intel.com" , "willy@infradead.org" , "vgoyal@redhat.com" , "linux-fsdevel@vger.kernel.org" , "nvdimm@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "linux-xfs@vger.kernel.org" Subject: Re: [dm-devel] [PATCH 0/6] dax poison recovery with RWF_RECOVERY_DATA flag Message-ID: References: <20211021001059.438843-1-jane.chu@oracle.com> <20211022015817.GY24307@magnolia> Precedence: bulk X-Mailing-List: nvdimm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211022015817.GY24307@magnolia> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html On Thu, Oct 21, 2021 at 06:58:17PM -0700, Darrick J. Wong wrote: > On Fri, Oct 22, 2021 at 01:37:28AM +0000, Jane Chu wrote: > > On 10/21/2021 4:31 AM, Christoph Hellwig wrote: > > > Looking over the series I have serious doubts that overloading the > > > slow path clear poison operation over the fast path read/write > > > path is such a great idea. > > Why would data recovery after a media error ever be considered a > fast/hot path? Not sure what you're replying to (the text is from me, the mail you are repling to is fom Jane), but my point is that the read/write got path should not be overloaded with data recovery. > A normal read/write to a fsdax file would not pass the > flag, which skips the poison checking with whatever MCE consequences > that has, right? Exactly! > pwritev2(..., RWF_RECOVER_DATA) should be infrequent enough that > carefully stepping around dax_direct_access only has to be faster than > restoring from backup, I hope? Yes. And thus be kept as separate as possible. 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 540BFC433F5 for ; Fri, 22 Oct 2021 05:39:15 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 CFF496101C for ; Fri, 22 Oct 2021 05:39:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CFF496101C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-532-GLTVtLRgO9evBa9D3rCDiQ-1; Fri, 22 Oct 2021 01:39:10 -0400 X-MC-Unique: GLTVtLRgO9evBa9D3rCDiQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 04A1D1006AA3; Fri, 22 Oct 2021 05:39:06 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A34377944C; Fri, 22 Oct 2021 05:39:05 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id AB8964A703; Fri, 22 Oct 2021 05:39:04 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 19M5cHvg009054 for ; Fri, 22 Oct 2021 01:38:18 -0400 Received: by smtp.corp.redhat.com (Postfix) id E192021568BB; Fri, 22 Oct 2021 05:38:17 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DC08521568B9 for ; Fri, 22 Oct 2021 05:38:12 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3FAA11875069 for ; Fri, 22 Oct 2021 05:38:12 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-359-gTlNVYuIMJ2i47GicVbzGA-1; Fri, 22 Oct 2021 01:38:08 -0400 X-MC-Unique: gTlNVYuIMJ2i47GicVbzGA-1 Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mdnFg-009lbb-Bd; Fri, 22 Oct 2021 05:38:00 +0000 Date: Thu, 21 Oct 2021 22:38:00 -0700 From: Christoph Hellwig To: "Darrick J. Wong" Message-ID: References: <20211021001059.438843-1-jane.chu@oracle.com> <20211022015817.GY24307@magnolia> MIME-Version: 1.0 In-Reply-To: <20211022015817.GY24307@magnolia> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-loop: dm-devel@redhat.com Cc: Jane Chu , "nvdimm@lists.linux.dev" , "dave.jiang@intel.com" , "snitzer@redhat.com" , "vishal.l.verma@intel.com" , "david@fromorbit.com" , "linux-kernel@vger.kernel.org" , "willy@infradead.org" , Christoph Hellwig , "dm-devel@redhat.com" , "vgoyal@redhat.com" , "linux-fsdevel@vger.kernel.org" , "dan.j.williams@intel.com" , "ira.weiny@intel.com" , "linux-xfs@vger.kernel.org" , "agk@redhat.com" Subject: Re: [dm-devel] [PATCH 0/6] dax poison recovery with RWF_RECOVERY_DATA flag X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dm-devel-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Oct 21, 2021 at 06:58:17PM -0700, Darrick J. Wong wrote: > On Fri, Oct 22, 2021 at 01:37:28AM +0000, Jane Chu wrote: > > On 10/21/2021 4:31 AM, Christoph Hellwig wrote: > > > Looking over the series I have serious doubts that overloading the > > > slow path clear poison operation over the fast path read/write > > > path is such a great idea. > > Why would data recovery after a media error ever be considered a > fast/hot path? Not sure what you're replying to (the text is from me, the mail you are repling to is fom Jane), but my point is that the read/write got path should not be overloaded with data recovery. > A normal read/write to a fsdax file would not pass the > flag, which skips the poison checking with whatever MCE consequences > that has, right? Exactly! > pwritev2(..., RWF_RECOVER_DATA) should be infrequent enough that > carefully stepping around dax_direct_access only has to be faster than > restoring from backup, I hope? Yes. And thus be kept as separate as possible. -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel