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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA5F2C433F5 for ; Thu, 26 May 2022 07:30:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346400AbiEZHa2 (ORCPT ); Thu, 26 May 2022 03:30:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41202 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346409AbiEZHa1 (ORCPT ); Thu, 26 May 2022 03:30:27 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 720F5814B8 for ; Thu, 26 May 2022 00:30:26 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 7E5A468AA6; Thu, 26 May 2022 09:30:22 +0200 (CEST) Date: Thu, 26 May 2022 09:30:22 +0200 From: Christoph Hellwig To: Qu Wenruo Cc: linux-btrfs@vger.kernel.org, Christoph Hellwig Subject: Re: [PATCH v2 4/7] btrfs: introduce new read-repair infrastructure Message-ID: <20220526073022.GA25511@lst.de> References: <531d3865-eb5b-d114-9ff2-c1b209902262@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <531d3865-eb5b-d114-9ff2-c1b209902262@suse.com> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Thu, May 26, 2022 at 11:06:31AM +0800, Qu Wenruo wrote: > Hi Christoph, I'm pretty sure the non-continuous bio problem is here for > all of our attempts to rework read-repair. Why is it a problem? Multiple discontiguous errors in the same bio are a very unusual error pattern. We need to handle it obviously, but it doesn't need to be optimized as it is so rare. The most common error pattern is that the entire read will return an error, followed by a single corrupted sector. > I'm wondering if there is some "dummy" page provided from block layer that > we can utilize? For reads nvme (and a few SCSI HBAs) support a bit bucket SGL for reads that discard parts of the data. Right now upstream none of this is supported, altough Keith has been looking into it (for a rather different use case) in nvme. This does not help with writes, never mind the fact that I would not want to use exotic and barely tested code and hardware features for a non time critical and rarely used error handling path..