From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ZFe79-0005xn-MX for mharc-grub-devel@gnu.org; Thu, 16 Jul 2015 04:01:55 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFe76-0005wM-G9 for grub-devel@gnu.org; Thu, 16 Jul 2015 04:01:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFe70-0008Mo-Fl for grub-devel@gnu.org; Thu, 16 Jul 2015 04:01:52 -0400 Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:33870) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFe70-0008MH-9E for grub-devel@gnu.org; Thu, 16 Jul 2015 04:01:46 -0400 Received: by wibud3 with SMTP id ud3so8131880wib.1 for ; Thu, 16 Jul 2015 01:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=ah46pBIi6anyaN0AD5anJ2wHVkCLIXs3TgyOylmiRMI=; b=Awz5mAlqCSMpKXkd6j7sXsN5TUU1ltUsP9hICsMwGb5LqqrSsWg6c7DWq1FYdYqIA6 94V5+QJD3pLHE1xr0cZovF3WRKRYGIzoaxo6RM0Z/Jk7PsvRt9TusIMhe6dREEa4Ixt9 8Q/r9eJEituzcnSAIynLVLFkVWRQheGZrTEmZqJ3lKAEMZGvL+yWE9GwxHh62zP1AHdW bhGtb9LL2VoEx0JU4xx4WTETlcdAvrSD9wg2Sv2IWWMmKJf3e7hn3S+3N9ROYV+5zZQK xllPEtVocJ7j7j5bnk1T3nCrz9fYoxcrbmEM0mkCGhHU04MrVJ/x9JJAxKy1epBJ+AMu 9AAw== X-Received: by 10.180.211.196 with SMTP id ne4mr2716736wic.23.1437033705410; Thu, 16 Jul 2015 01:01:45 -0700 (PDT) Received: from ?IPv6:2a02:1205:34c8:dc00:863a:4bff:fe50:abc4? ([2a02:1205:34c8:dc00:863a:4bff:fe50:abc4]) by smtp.gmail.com with ESMTPSA id uo6sm11646589wjc.1.2015.07.16.01.01.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jul 2015 01:01:44 -0700 (PDT) Message-ID: <55A764E7.7060705@gmail.com> Date: Thu, 16 Jul 2015 10:01:43 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Andrei Borzenkov Subject: Re: [RFD] diskfilter stale RAID member detection vs. lazy scanning References: <20150628210655.6dfdbd9a@opensuse.site> <55A6A104.6060407@gmail.com> <20150716064201.0249fe57@opensuse.site> In-Reply-To: <20150716064201.0249fe57@opensuse.site> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="e6OsAmvUNGoBnrQXhMt9r7D8wmuPsknl9" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::230 Cc: The development of GNU GRUB X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 08:01:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --e6OsAmvUNGoBnrQXhMt9r7D8wmuPsknl9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16.07.2015 05:42, Andrei Borzenkov wrote: > =D0=92 Wed, 15 Jul 2015 20:05:56 +0200 > Vladimir '=CF=86-coder/phcoder' Serbinenko =D0=BF=D0= =B8=D1=88=D0=B5=D1=82: >=20 >> On 28.06.2015 20:06, Andrei Borzenkov wrote: >>> I was looking at implementing detection of outdated RAID members. >>> Unfortunately it appears to be fundamentally incompatible with lazy >>> scanning as implemented currently by GRUB. We simply cannot stop >>> scanning for other copies of metadata once "enough" was seen. Because= >>> any other disk may contain more actual copy which invalidates >>> everything seen up to this point. >>> >>> So basically either we officially admit that GRUB is not able to dete= ct >>> stale members or we drop lazy scanning. >>> >>> Comments, ideas? >>> >> We don't need to see all disks to decide that there is no staleness. I= f >> you have an array with N devices and you can lose at most K of them, >> then you can check for staleness after you have seen max(K+1, N-K) >> drives. Why? >> >=20 > It's not the problem. The problem is what to do if you see disk with > generation N+1 after you assembled array with generation N. This can > mean that what we see is old copy and we should through it away and > start collecting new one. If I read Linux MD code correctly, that is > what it actually does. And this means we cannot stop scanning even > after array is complete. >=20 While it's true that it's possible that all the members we have seen are stale, it shouldn't be common and it's not the biggest problem. Biggest problem is inconsistency. We can never guarantee of having seen all the disks as they may not be eeven visible through firmware but it shouldn't stop us from fixing the inconsistency problem. > Extreme example is three-pieces mirror where each piece is actually > perfectly valid and usable by itself so losing two of them still means > we can continue to work with remaining one. >=20 Mirrors get completely assembled in my patch. --e6OsAmvUNGoBnrQXhMt9r7D8wmuPsknl9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREKAAYFAlWnZOcACgkQmBXlbbo5nOshGwD/Y+q4w31/7o71evAlnOUh1H2M B6oNBwP50i8Tye0+FjwBAJTG+8Mcj4JXvCqitDPt63W17kcgfuTxLZVqmi7863xw =mmJF -----END PGP SIGNATURE----- --e6OsAmvUNGoBnrQXhMt9r7D8wmuPsknl9--