From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ZFa3o-0003G0-KI for mharc-grub-devel@gnu.org; Wed, 15 Jul 2015 23:42:12 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFa3l-0003Ed-Di for grub-devel@gnu.org; Wed, 15 Jul 2015 23:42:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFa3i-0002Nf-0G for grub-devel@gnu.org; Wed, 15 Jul 2015 23:42:09 -0400 Received: from mail-lb0-x231.google.com ([2a00:1450:4010:c04::231]:36572) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFa3h-0002Nb-OC for grub-devel@gnu.org; Wed, 15 Jul 2015 23:42:05 -0400 Received: by lbbpo10 with SMTP id po10so36052125lbb.3 for ; Wed, 15 Jul 2015 20:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; bh=2Tsh2hUKXNF0QnS/ns3IVEaHxye4S+k2AhwFPhCOock=; b=YdF9Uh0OXTJOmHCR9i/fphZhV6x6M6rHcI5KjzpKvYO1/jR1aVbSC2HMldUS4XAuPi xSUNcTDR/exJpfBzQKCqlvf1J4GLyNUNfTz8pw7pRkYsq1CPE38e/NYEQJsMhqFjWxJm TZ000QVAbzLWO5Bj98T+rqRQq8MtQO2abjQExCvy7z0OXMMslH9cPXcP8oInz6fOmu+T Yx4VZUnWirMsUW7ugNLD5wUTlwgLgqNeQmQ5K0MrY1MTvOQrTAGu9BsDq/61EvCx9bRG BmKtsIc1rToSARZaswqfNYZoQPs3CC/icqRHeZQKWTcVuDgsb0Ax6qAR4Ej5WBIgOxTq EXSA== X-Received: by 10.152.225.164 with SMTP id rl4mr7310506lac.38.1437018123653; Wed, 15 Jul 2015 20:42:03 -0700 (PDT) Received: from opensuse.site (ppp91-77-243-215.pppoe.mtu-net.ru. [91.77.243.215]) by smtp.gmail.com with ESMTPSA id df8sm1676931lac.3.2015.07.15.20.42.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jul 2015 20:42:02 -0700 (PDT) Date: Thu, 16 Jul 2015 06:42:01 +0300 From: Andrei Borzenkov To: Vladimir =?UTF-8?B?J8+GLWNvZGVyL3BoY29kZXIn?= Serbinenko Subject: Re: [RFD] diskfilter stale RAID member detection vs. lazy scanning Message-ID: <20150716064201.0249fe57@opensuse.site> In-Reply-To: <55A6A104.6060407@gmail.com> References: <20150628210655.6dfdbd9a@opensuse.site> <55A6A104.6060407@gmail.com> X-Mailer: Claws Mail 3.11.0 (GTK+ 2.24.28; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Xn=x.wVidSiK3OHm7y9zQe6"; protocol="application/pgp-signature" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::231 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 03:42:10 -0000 --Sig_/Xn=x.wVidSiK3OHm7y9zQe6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =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: > 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. > >=20 > > So basically either we officially admit that GRUB is not able to detect > > stale members or we drop lazy scanning. > >=20 > > Comments, ideas? > >=20 > We don't need to see all disks to decide that there is no staleness. If > 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. 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. > Let those disks have generation numbers g_0,...,g_{N-1}. Our goal is to > find the largest number G s.t. number of indices with > g_i >=3D G is at least N-K. > In most common case when you have seen K+1 disks all of them will have > the same generation number > g_0=3Dg_1=3D...=3Dg_{K} > Then we know that > G<=3Dg_0 > Suppose not then all of 0,...,K are stale and we have lost K+1 drives > which contradicts our goal. > On the other hand when we have seen N-K devices we know that > G>=3Dmin(g_0,...,g_{N-K-1}) > as with G=3Dmin(g_0,...,g_{N-K-1}) we already have N-K disks. >=20 > In cases other than mirror usually K+1<=3DN-K and so we don't even need to > scan for more disks to detect staleness. Yes, that was my idea initially as well. Unfortunately the problem here is not math.=20 > The code will be slightly tricky as it has to handle tolerating > staleness if there are too little disks but it's totally feasible. Let > me figure out the rest of math and write a prototype. > > _______________________________________________ > > Grub-devel mailing list > > Grub-devel@gnu.org > > https://lists.gnu.org/mailman/listinfo/grub-devel > >=20 >=20 >=20 --Sig_/Xn=x.wVidSiK3OHm7y9zQe6 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlWnKAoACgkQR6LMutpd94zcDgCfQbsn0KpVe6mNuJmJvP1B+rvX Hm8AoLGSlQOa1tiuToKv2JEr1+TSa0OR =xGe3 -----END PGP SIGNATURE----- --Sig_/Xn=x.wVidSiK3OHm7y9zQe6--