Description of problem:

Single byte corruption in metadata which is even reported by thin_check is not giving correct 'failing' exit code - so thin-pool gets activated with lots of kernel error messages.

Here is an example:

Commands used to create setting:

lvcreate -T -L20 -V10 -n LV1 vg/pool
lvcreate -T -V10 -n LV2 vg/pool

mkfs.ext2 /dev/vg/LV1
mkfs.ext2 /dev/vg/LV2

lvs looklike:

  LV              VG Attr       LSize  Pool Data%
  LV1             vg Vwi---tz-- 10.00m pool 5.62
  LV2             vg Vwi---tz-- 10.00m pool 5.62
  [lvol0_pmspare] vg ewi-------  2.00m
  pool            vg twi---tz-- 20.00m      5.62
  [pool_tdata]    vg Twi------- 20.00m
  [pool_tmeta]    vg ewi-------  2.00m


Corruption is made by:

dd if=/dev/zero of=/dev/vg/repair bs=1 seek=40960 count=1
(thin-pool has been deactivated and metadata device swapped out of thin-pool)

Thin check on such metadata gives this:

# thin_check @TESTDIR@/dev/@PREFIX@vg/repair
examining superblock
examining devices tree
examining mapping tree
  thin device 1 is missing mappings [160, -]
    bad checksum in btree node


And instead of 'fail' - it returns '0' as OK.


# thin_dump gives this:

<superblock uuid="" time="0" transaction="2" data_block_size="128" nr_data_blocks="320">
  <device dev_id="1" mapped_blocks="9" transaction="0" creation_time="0" snap_time="0">
    <range_mapping origin_begin="0" data_begin="0" length="4" time="0"/>
    <range_mapping origin_begin="128" data_begin="4" length="4" time="0"/>


thin_repair (assuming confused as other with bad checksum):

# thin_repair -i /dev/vg/repair -o /dev/vg/fixed
bad checksum in btree node


Version-Release number of selected component (if applicable):
<= device-mapper-persistent-data-0.2.7

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:

thin_check returns 0 for bad metadata
thin_repair is not fixing them


Expected results:


Additional info: