From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1R91Y8-0008Ky-Qa for mharc-grub-devel@gnu.org; Wed, 28 Sep 2011 17:20:16 -0400 Received: from eggs.gnu.org ([140.186.70.92]:48040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R91Y5-0008I2-8B for grub-devel@gnu.org; Wed, 28 Sep 2011 17:20:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R91Y3-0007FC-Nw for grub-devel@gnu.org; Wed, 28 Sep 2011 17:20:13 -0400 Received: from mail-fx0-f41.google.com ([209.85.161.41]:39198) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R91Y3-0007Ez-FV for grub-devel@gnu.org; Wed, 28 Sep 2011 17:20:11 -0400 Received: by fxh17 with SMTP id 17so1274594fxh.0 for ; Wed, 28 Sep 2011 14:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=TRYpxMxSZhPBVuSU9/iH8ELJLHamKFBS0gM/W+do+Lk=; b=eezmm59DYWBHZy6M8VC+/8o8eJU6w1lFu3rutIHCs8/AuiJFR7hIaVAPWotLklJ9yx y88OQBZbvvrgqSaVuZYu2w85fVXgGhsY5AeIKuqVik5ybYWKLgT7k8SMqdOtU5wz03s9 L7dtxGdnIA0wnjtnOF3/9+KLuI+hXgq+sTY+g= Received: by 10.223.101.84 with SMTP id b20mr15002788fao.94.1317244810546; Wed, 28 Sep 2011 14:20:10 -0700 (PDT) Received: from debian.x201.phnet (67-232.197-178.cust.bluewin.ch. [178.197.232.67]) by mx.google.com with ESMTPS id u18sm46940fac.24.2011.09.28.14.20.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Sep 2011 14:20:08 -0700 (PDT) Message-ID: <4E838F85.6060001@gmail.com> Date: Wed, 28 Sep 2011 23:20:05 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: [Patch] Robustly search for ZFS labels & uberblocks References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE1D9D5C1CB39AC2B3E0F048B" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.161.41 Cc: Zachary Bedell 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: Wed, 28 Sep 2011 21:20:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE1D9D5C1CB39AC2B3E0F048B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Could you please split this patch? In particular the removing of dprintf takes to much of this patch and makes it unreadable. Note that we don't comment out the code, we only remove it. On 19.09.2011 20:45, Zachary Bedell wrote: > Greetings, > > In working with ZFSonLinux, I found myself with a number of somewhat in= constant pools which failed either when running grub-probe or at boot tim= e. In all cases, these pools were importable by the ZFS driver and compl= eted a `zpool scrub` with no errors reported, but still Grub wasn't able = to touch the pools. In most (but not all) cases, running `zpool scrub` m= ade the pool accessible to Grub again, though obviously that was less tha= n helpful for boot-time failures. > > I'm including an (unfortunately rather large) patch to Grub's ZFS code = which fixes several edge cases where Grub is unable to read a pool which = is otherwise valid as far as the full ZFS driver is concerned. Changes i= nclude: > > ashift: > > * Support non-default values of ashift pool attribute. When ashift is = increased beyond 10, the size of the uberblocks changes. Scan to find ub= erblocks must account for this and skip over the extra padding. Based on= patch to Grub 0.97 by Hans Rosenfeld at http://www.illumos.org/issues/13= 03 > > > Label parsing changes: > > * Access the two end-device labels at label-size aligned location rathe= r than device_end-(2*label_size). On-disk spec document incorrectly desc= ribes end-label locations. Adapted from Grub 0.97 behavior. > > * Scan all readable labels for uberblocks and accept the one with the h= ighest txg/create date. Previously UB scan would stop if a valid UB was = found in Label 0 without checking for newer UB's in the other labels. Al= l labels must be scanned as a more recent block may be found in the other= labels in certain circumstances. This fixes a case where Grub would be = unable to access a ZFS system unless the pool was scrubbed first (but ZFS= itself saw no problems & scrub reported zero errors). > > * Verify that uberblock txg is greater than that of the label before ac= cepting the UB so that partially written UB's are not considered. > > * Verify that underlying data pointed by uberblock ub_rootbp has valid = checksums before accepting the UB. This gives some possibility of bootin= g from a technically invalid pool and effectively falls back to older ube= rblocks in a case where the correct uberblock is damaged. > > * Store pool uuid found during zfs_mount to grub_zfs_data in order to p= revent duplicated logic in zfs_uuid. > > > Data integrity: > > * Verify checksum in grub_read_data before accepting block. Attempt to= read backup DVA's if checksum on first fails. Previously backup DVA's w= ere checked only if the physical read failed, not if bad data was read wi= thout error. This resulted in pools which were valid and readable by ZFS= (and transparently healed by ZFS' read behavior) being rejected by Grub.= > > > Logging/Debugging: > > * Provide more debugging output describing inconsistencies found in poo= l. > > * Remove superflous debugging output to reduce bootup time in verbose m= ode to a mangeable level (~30min down to ~5min to boot w/ 'debug=3Dall' i= n grub.cfg) > > > > I do apologies for the monolithic patch. I took a second look at the c= hanges to try to pull certain elements apart, but I ended up in several s= ituations where the test pools I have snapshotted in VM's each hit two or= more of the issues above making testing in isolation difficult. The tot= al change set is able to probe and boot from all of the odd (as well as a= ll of the normal) pools that I have on hand. =20 > > If remixing this patch in some way would help in integrating it, I'd we= lcome any feedback on how to better present the changes. > > Best regards, > Zac Bedell > > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enigE1D9D5C1CB39AC2B3E0F048B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk6Dj4UACgkQNak7dOguQgl+JAEAnOloWgTIlxE0E0EMd5v46AuV +jj4u4C4BuFoXITOjdEBAI7RSLTHHwkLxFVOU01TgBfzNVVZ1JmK05dRWKv+WWXE =EqUa -----END PGP SIGNATURE----- --------------enigE1D9D5C1CB39AC2B3E0F048B--