Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3116979pxu; Sat, 19 Dec 2020 12:42:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJwfGsv5c2MWpjeGyVASVNsciv2aitdSw0Fh3ri5KlMpofyGx/BAGvbE0lwFv6iLVRhXn4Av X-Received: by 2002:a17:906:924a:: with SMTP id c10mr9519926ejx.113.1608410544149; Sat, 19 Dec 2020 12:42:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608410544; cv=none; d=google.com; s=arc-20160816; b=TbqS7ZgEQG2ekwSLcyT6aKaniZBED6GCg0/h1cs1e5vSos8b95lXyrwJ4cva6nmwG7 01mTs/6QVBMs2uIQjv8V5jp8//MkNQvoMW22E4+2ovJjQW2Qm24rgYAB/SLfTdBFAunE s3+kINNSq4BV7lO1AtGxrBxZUrRIqUHZJmWetOaT3USfX5onV7Q9Z51E0acwYvPYhIvf RfovaycqPjyP2faAdjx8pfvviuEkuJRg4EXyTKac3sJ/1hIUyHIclMt1B/hAE2OnJ43D Cv0dSlqlpFTtQl6IUegROyYo87jsUb5ZzsPGZtxCyG6rg3AqfMmjEcjC+0my3iDkZe+9 OE0Q== 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:from:references :cc:to:subject; bh=NWRQRsJikhU8JjZlOECdQsRbqWLwT+goWo1S7Ge0gOc=; b=iC9bRaGtruUIFpflA7RHjeXruAxNlATVDYWKYL6rLq/4XHeXCAgVVQ3aaeSaTh0ofX 62kJb4j3ngZSz8vl1HAv+0ZgRUiHfgj269aFF8KgSM9Ii4uL1o4yTHCFSqwqGmpwykEx CB4QZRrkGaeZVQlSpIn/5BSMnzHdarlwMjrGGnawt9gqiOlb+kB6SGwpQL7BSJpuZVOK p9jNhIeMjShUVrrEeAhWWX64XYzLo+PcYodgxHo7m3qnNuBhQhyj+O2m6uxhFMsLyKyH 89ZgS8eEJijDyUhpu/g+b2a/YgbbGB5D8cDxX4B8dFW1PTzGe4dfdoKZWx4kHGGLlSse JNSA== 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 n8si8222282edy.54.2020.12.19.12.41.46; Sat, 19 Dec 2020 12:42:24 -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 S1727370AbgLSUkd (ORCPT + 99 others); Sat, 19 Dec 2020 15:40:33 -0500 Received: from smtp.hosts.co.uk ([85.233.160.19]:36326 "EHLO smtp.hosts.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726238AbgLSUkd (ORCPT ); Sat, 19 Dec 2020 15:40:33 -0500 X-Greylist: delayed 2259 seconds by postgrey-1.27 at vger.kernel.org; Sat, 19 Dec 2020 15:40:32 EST Received: from host86-149-69-253.range86-149.btcentralplus.com ([86.149.69.253] helo=[192.168.1.65]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1kqiQd-000BHA-9x; Sat, 19 Dec 2020 20:02:11 +0000 Subject: Re: [RFC PATCH] badblocks: Improvement badblocks_set() for handling multiple ranges To: Coly Li , 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> From: antlists Message-ID: <3f4bf4c4-1f1f-b1a6-5d91-2dbe02f61e67@youngman.org.uk> Date: Sat, 19 Dec 2020 20:02:11 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <20201203171535.67715-1-colyli@suse.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? "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. 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 don't quite see why mdraid should need a badblocks list given modern disk drives. 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?" Cheers, Wol