linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: "Stuart D. Gathman" <stuart@gathman.org>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: Dave Cohen <linux-lvm@dave-cohen.com>
Subject: Re: [linux-lvm] repair pool with bad checksum in superblock
Date: Fri, 23 Aug 2019 11:29:29 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LRH.2.21.1908231127490.3542@fairfax.gathman.org> (raw)
In-Reply-To: <07a8641dd1c8c10b24a65f546557685c@assyoma.it>

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 <stuart@gathman.org>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

  reply	other threads:[~2019-08-23 15:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-23  0:18 [linux-lvm] repair pool with bad checksum in superblock Dave Cohen
2019-08-23  8:59 ` Zdenek Kabelac
2019-08-23 11:40   ` Dave Cohen
2019-08-23 12:47     ` Zdenek Kabelac
2019-08-23 14:58       ` Gionatan Danti
2019-08-23 15:29         ` Stuart D. Gathman [this message]
2019-08-25  2:13       ` Dave Cohen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LRH.2.21.1908231127490.3542@fairfax.gathman.org \
    --to=stuart@gathman.org \
    --cc=linux-lvm@dave-cohen.com \
    --cc=linux-lvm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).