Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3408867pxu; Sun, 20 Dec 2020 01:48:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJxY3PW4hjdA7klXUAC87yAtnyPQIMlNcAC3u4aeeVtCfGh0/SbRyQyfkZszYVSR92R4LBmM X-Received: by 2002:aa7:d916:: with SMTP id a22mr11640074edr.122.1608457710182; Sun, 20 Dec 2020 01:48:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608457710; cv=none; d=google.com; s=arc-20160816; b=eXpi+xbmjJwd3ou98KdjxJQvFF9+c3NuE9cyKPj94dUG8ls0i7174+AI1FIeQx/exL 1VHFx4fvgUjN1rxZaIrYG7tIVwMGD9txEb1He1IClC3uvKBYXVaTQSXrTr0bh5VZQ5sO 9makZSuZliMBd9z9cPGkH/Gs0G/9D1JD57MLtnSyOepi4gm0f4JVRkW6lkoi1SW1COnr 8MEeXZDlhMEjMyEorBJK7jalh7lPAppa4HsBBIRSeYPENO+EObw0LJU1+TQkCb0JXdtD saNIwlTP0Z18QvR64AVypsm0MbKYO7VPtWe/2IGHYP0wS9+H4He7xHeswLHA8sOES2uS M4pA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to; bh=Yhu4Ul0+sS9znviVirUi+vF/LTbRPJbYSRjR9iM02L0=; b=Q74wdws45gNJvu5aiyWHqYWKQ8Mn7lqnYQHxSx601UcIkML6x6FbC57bWJRxNNFrlC dhV4eIiSVKvGpBEWj+KXxAJcQ+xppceiyqxQtiUHItzfMJqd0LayGvc7ssZF6MVi/PwY I4vkdTwnLJ51OVOEnXJPTg+QZvrr2QCiOGk/BUG2unI5/vcoz4d7fhMFVRASlOG2lDb+ ytAN3hyKu34S/sR9oGgRTQ7fqT6VSVzyirkMtpwTnwqBceQPKaAWJDvgYpC33BL9RfUg ZLNOCWOrXpC6+adQbTlK/awW+hMtTdWa+vKmF1TqEPCCJ1h+96Cga0QQQt2nDvK8dgMK pfCw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v26si2003517ejc.336.2020.12.20.01.48.08; Sun, 20 Dec 2020 01:48:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727375AbgLTJrA (ORCPT + 99 others); Sun, 20 Dec 2020 04:47:00 -0500 Received: from mx2.suse.de ([195.135.220.15]:33048 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726377AbgLTJrA (ORCPT ); Sun, 20 Dec 2020 04:47:00 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B8CDCAC7B; Sun, 20 Dec 2020 09:46:18 +0000 (UTC) To: antlists , axboe@kernel.dk, dan.j.williams@intel.com, vishal.l.verma@intel.com Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, linux-nvdimm@lists.01.org References: <20201203171535.67715-1-colyli@suse.de> <3f4bf4c4-1f1f-b1a6-5d91-2dbe02f61e67@youngman.org.uk> From: Coly Li Subject: Re: [RFC PATCH] badblocks: Improvement badblocks_set() for handling multiple ranges Message-ID: Date: Sun, 20 Dec 2020 17:46:14 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <3f4bf4c4-1f1f-b1a6-5d91-2dbe02f61e67@youngman.org.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/20/20 4:02 AM, antlists wrote: > On 03/12/2020 17:15, Coly Li wrote: >> This patch is an initial effort to improve badblocks_set() for setting >> bad blocks range when it covers multiple already set bad ranges in the >> bad blocks table, and to do it as fast as possible. > > Is this your patch, or submitted as part of the bug report? This is not finished yet. The final version should go into upstream as a fix for current badblocks routines. > > "Heavily based on MD badblocks code from Neil Brown" > > How much has this code got to do with the mdraid subsystem? Because > badblocks in mdraid has an appalling reputation, with many people > wanting to just rip it out. This is in-memory data structure management which is almost irrelevant to md raid or other on-disk layout. > > If this code is separate from the mdraid implementation, any chance you > can work with it, and fix that at the same time? Or make it redundant! I This is 100% separated from md raid, as well as current badblocks code, it is just about combine or split some [start, length] extent in a table. The purpose of this patch is to fixing some reported issue from users and our customers. > don't quite see why mdraid should need a badblocks list given modern > disk drives. > For me the motivation is just people report bugs and I fix it. If there is new code to replace it in upstream, then I just continue to maintain the new code for our users and customers. > And it's on my to-do list (if I can find the time!!!) to integrate > dm-integrity into mdraid, at which point md badblocks should be irrelevant. > > Hope I'm not being a shower of cold water, and if you want to fix all > this, good on you, but to the extent that this is relevant to > linux-raid, I think a lot of people will be asking "What's the point?" Currently blocks/badblocks.c is used by md raid and nvdimm code, and the badblocks table is irrelevant to any of these two subsystems. If there will be better code for similar or better functionality, it should be cool. For me, if the reporting bug is fixed, no difference in my view :-) Thanks. Coly Li