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@xxxxxxxxxxx>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
