From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1a3FEm-0006hU-3L for mharc-grub-devel@gnu.org; Sun, 29 Nov 2015 22:34:48 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53306) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3FEj-0006h6-EF for grub-devel@gnu.org; Sun, 29 Nov 2015 22:34:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3FEe-0003tJ-Dt for grub-devel@gnu.org; Sun, 29 Nov 2015 22:34:45 -0500 Received: from mail-lf0-x234.google.com ([2a00:1450:4010:c07::234]:33410) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3FEe-0003t7-5p for grub-devel@gnu.org; Sun, 29 Nov 2015 22:34:40 -0500 Received: by lfaz4 with SMTP id z4so180639133lfa.0 for ; Sun, 29 Nov 2015 19:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=8kfoqPCH0XEzT93e3F+EEd+XUCQ+4vsYN7RMsYfp8LM=; b=kMlugLuSX4uysLLlzGJfRayshUCmX52VoRy/NVbVJ8YXtuvoz/pwpXVZWdFH8EdO8k m+aohcLN7Z7FgpjKWuK5wCzcfkrEYV1cdLXfK0OQaolzOF3YU5xn6vxnx87vNB6RaIi0 67x46Lx2FPsjl/fhVaG+e4W5XytsgHkESVwwdxDjpnfrl7sjwM0uCPXxMif3H7Bj/Sf3 i/v99pcyEGbpd7a9dAH8hNIC0MAPr/AFN/OCcfTQFab2++Pm9sIPeJS1wqfCUuGDouWk Qv8Jz28ct6mHgB4eFcq3s+QfoSI7KQchDyC3BkeMZGV7pUoVlaaDA4Ok2IyvE6O0Oqap ZqXw== X-Received: by 10.25.19.168 with SMTP id 40mr25420895lft.68.1448854479438; Sun, 29 Nov 2015 19:34:39 -0800 (PST) Received: from [192.168.1.41] (ppp91-76-25-247.pppoe.mtu-net.ru. [91.76.25.247]) by smtp.gmail.com with ESMTPSA id g5sm6848926lbd.26.2015.11.29.19.34.38 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Nov 2015 19:34:38 -0800 (PST) Subject: Re: [RFD] diskfilter stale RAID member detection vs. lazy scanning To: grub-devel@gnu.org References: <20150628210655.6dfdbd9a@opensuse.site> <55A6A104.6060407@gmail.com> <55A6D4FA.7000400@gmail.com> From: Andrei Borzenkov X-Enigmail-Draft-Status: N1110 Message-ID: <565BC3CD.5050509@gmail.com> Date: Mon, 30 Nov 2015 06:34:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <55A6D4FA.7000400@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gmUBc9o9UXcFh61qAnFLGiVJhFLXLilx0" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c07::234 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: Mon, 30 Nov 2015 03:34:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gmUBc9o9UXcFh61qAnFLGiVJhFLXLilx0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 16.07.2015 00:47, Vladimir '=CF=86-coder/phcoder' Serbinenko =D0=BF=D0=B8= =D1=88=D0=B5=D1=82: > On 15.07.2015 20:05, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote: >> 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? >> >> Let those disks have generation numbers g_0,...,g_{N-1}. Our goal is t= o >> 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. >> >> In cases other than mirror usually K+1<=3DN-K and so we don't even nee= d to >> scan for more disks to detect staleness. >> 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. > Untested patch implementing these ideas, just to illustrate I am not sure about insert_array(). Let's consider raid1 which lost one member which was replaced by hot spare and was left in a system. So we now have three disks A(G) A(G+1) B(G+1) First we see A(G+1) and insert it in array. Later we see A(G). If I follow code in insert_array(), we simply overwrite previous disk reference without checking. So we have leaked open file but what's worse we lost reference to the actual member. --gmUBc9o9UXcFh61qAnFLGiVJhFLXLilx0 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.0.22 (GNU/Linux) iEYEARECAAYFAlZbw80ACgkQR6LMutpd94xSgACgih5ezEQvsTxlpeQ7kUlUGGdA kVYAnicQYEzJWBfNZJ8uUlJ4m6GO8/Dd =RjrL -----END PGP SIGNATURE----- --gmUBc9o9UXcFh61qAnFLGiVJhFLXLilx0--