From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx26.extmail.prod.ext.phx2.redhat.com [10.5.110.67]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BB97A5D6B2 for ; Fri, 23 Aug 2019 15:29:37 +0000 (UTC) Received: from mail.gathman.org (mail.gathman.org [70.184.247.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A6FF58980EE for ; Fri, 23 Aug 2019 15:29:36 +0000 (UTC) Date: Fri, 23 Aug 2019 11:29:29 -0400 (EDT) From: "Stuart D. Gathman" In-Reply-To: <07a8641dd1c8c10b24a65f546557685c@assyoma.it> Message-ID: References: <36c36310-1771-fed1-e208-3db7c0f9c768@redhat.com> <07a8641dd1c8c10b24a65f546557685c@assyoma.it> MIME-Version: 1.0 Subject: Re: [linux-lvm] repair pool with bad checksum in superblock Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit To: LVM general discussion and development Cc: Dave Cohen On Fri, 23 Aug 2019, Gionatan Danti wrote: > Il 23-08-2019 14:47 Zdenek Kabelac ha scritto: >> Ok - serious disk error might lead to eventually irrepairable metadata >> content - since if you lose some root b-tree node sequence it might be >> really hard >> to get something sensible (it's the reason why the metadata should be >> located >> on some 'mirrored' device - since while there is lot of effort put into >> protection again software errors - it's hard to do something with >> hardware error... > > Would be possible to have a backup superblock, maybe located on device end? > XFS, EXT4 and ZFS already do something similar... On my btree file system, I can recover from arbitrary hardware corruption by storing the root id of the file (table) in each node. Leaf nodes (with full data records) are also indicated. Thus, even if the root node of a file is lost/corrupted, the raw file/device can be scanned for corresponding leaf nodes to rebuild the file (table) with all remaining records. Drawbacks: deleting individual leaf nodes requires changing the root id of the node requiring an extra write. (Otherwise records could be included in some future recovery.) Deleting entire files (tables) just requires marking the root node deleted - no need to write all the leaf nodes. -- Stuart D. Gathman "Confutatis maledictis, flamis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial.