Received: by 2002:a19:f614:0:0:0:0:0 with SMTP id x20csp37215lfe; Fri, 15 Apr 2022 18:16:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJww5vLwc5JzZnG5Q4tn2DiCVM1mgkJBNH7KdGBIF6Al6KfB2Y3lttyhh3Mni47Vkq3AisPe X-Received: by 2002:a17:903:1cd:b0:158:eaa9:7291 with SMTP id e13-20020a17090301cd00b00158eaa97291mr471646plh.113.1650071777849; Fri, 15 Apr 2022 18:16:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650071777; cv=none; d=google.com; s=arc-20160816; b=wBJrEheuqz4jNS1puimgCXBo/FU46RvLmz3IbxFhu1ezfOzLhSFV+B3PZo0HyU0y34 aUp91LTNQWnGaJ5xGl83Ry5/ctUxAcCFgZLT6ZxncRz0ApWX98MBVJE4LZhU51fcGTmv 0jzYJ94GQkJBIe0+S5Qa7K0K3EqG6CmpuOJsr1DSpEv+FI+wyLismNY44aPRQSOhe6kw gz664nyZVr2NuFIz8xFvHNkRzEFYLVK28UkniHRz2dSPETTmHUxdF8I/GgXavvCnLe5b hdF4X8l2wieP5ePtYqBq7E2g8TDjRLPczsey6RGw2XKn2mz86mr59HYSTy2MEkvX6uGh Tf+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=yLtaN1T6CZH61bsOXekhePNRAAxP7cjTyn667qnmUdQ=; b=VgXz+BC7v+BEUKMR89VV5HxwZsZ2O6T2AcNUucAOSs5TmvQACklh27KsRBT0d6EX6j UvBqg1wvFIC9YU+WSace/EYVGVYYWzXKD5FKmNIE4iPVhRAYrc+sV1xptuDaXONkJRJS /d1M3PQ4w1R1uN4faYFt13f0zEzJaUok06Kr77GbRqfRnpFXNc7di8c5RzciX+0VxcjJ PD7HqxTuipCwVuwQ9Od03VXGEGk4w6I/TY3o6B42JGN6a7PIP7ktcWPz+T4saWXg10BB 4LNU2eurFIaJZmfUonfZt4/Uc9gG67sK1bCyY018fpHF7F7NzjKTaXThS+UqUNBhK28I 8Icg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=nvyu91bk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id qe14-20020a17090b4f8e00b001cbaf9b7f41si5789287pjb.76.2022.04.15.18.16.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 18:16:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=nvyu91bk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 125175AEFE; Fri, 15 Apr 2022 17:52:44 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230009AbiDNLJK (ORCPT + 99 others); Thu, 14 Apr 2022 07:09:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242369AbiDNLJI (ORCPT ); Thu, 14 Apr 2022 07:09:08 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C4BE70CDD; Thu, 14 Apr 2022 04:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649934404; x=1681470404; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=lpK5uTsGwurYPm1EZSv9KDNdr4wZT3Uq8fQlImPzuTw=; b=nvyu91bkMdkz1y/WeyNHHECE9DuSUMZzQsCVTbKVzs83LGt03xqJqULY aYNKexW8d9DtoRIDnqjqytMwibliM6f8VDAw6CnUIi5tAfC/fjHZVPCXK O9utWiTf+DsnXDqTpOqanVKaQc4qCDn9wK0Spn3IbZVam7yjp418fdIIp B5mKOentbRtjyTDkO4OeUkArflvVFyUmh2YCcdkLp3O91utRNTFPBjgYP ETQFzq4/TZssJsU7kgG7p9SivYvHeridRFdxvnn8+EAYDRcmEtF/j3kY6 UuSCZ7wtmiJz4bSzIkQX4OO1eqXuM/zyl5WtSp3TSbj5gYgHdGnZJ3zNk g==; X-IronPort-AV: E=McAfee;i="6400,9594,10316"; a="287960501" X-IronPort-AV: E=Sophos;i="5.90,259,1643702400"; d="scan'208";a="287960501" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2022 04:06:43 -0700 X-IronPort-AV: E=Sophos;i="5.90,259,1643702400"; d="scan'208";a="573750098" Received: from mtkaczyk-mobl.ger.corp.intel.com (HELO localhost) ([10.213.16.42]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2022 04:06:41 -0700 Date: Thu, 14 Apr 2022 13:06:36 +0200 From: Mariusz Tkaczyk To: "NeilBrown" Cc: Song Liu , linux-raid@vger.kernel.org, linux-block@vger.kernel.org, LKML , Lennart Poettering Subject: Re: [PATCH/RFC] md: remove media-change code Message-ID: <20220414130636.00002eca@linux.intel.com> In-Reply-To: <164991636542.11576.2282590308338864748@noble.neil.brown.name> References: <164991636542.11576.2282590308338864748@noble.neil.brown.name> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 14 Apr 2022 16:06:05 +1000 "NeilBrown" wrote: > md only ever used the media-change interfaces to trigger a partition > rescan once the array became active. Normally partition scan only > happens when the disk is first added, and with md the disk is typically > inactive when first added. > > This rescan can now be achieved by simply setting GD_NEED_PART_SCAN. > So do that, and remove all the rescan. > Hi Neil, I experimented in this area in the past, mainly on IMSM (external metadata). My problem is described here: https://lore.kernel.org/linux-raid/SA0PR11MB4542ECA84F72506B39C3C9F1FFEE0@SA0PR11MB4542.namprd11.prod.outlook.com/ I lost reproduction on newer kernels, probably changes in block layer hide issue, it seems to be time race. The change you proposed could bring the issue back. The current way is working, so I consider your change as potentially dangerous. Anyway, I will help with testing if Song decides to take it. For external metadata we should impose partition read after mdmon start (when md device becomes RW), so it should be synchronized with mdadm. It could break autostart functionality for native metadata (if it is still in use). Eventually, external metadata should be handled separately. Thanks, Mariusz