Bug 1019217 - Thin_check doesn't return error exit code for broken metadata [NEEDINFO]
Thin_check doesn't return error exit code for broken metadata
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: device-mapper-persistent-data (Show other bugs)
Unspecified Unspecified
high Severity medium
: rc
: 6.5
Assigned To: Joe Thornber
Depends On:
Blocks: 1020825
  Show dependency treegraph
Reported: 2013-10-15 06:06 EDT by Zdenek Kabelac
Modified: 2013-11-21 18:00 EST (History)
9 users (show)

See Also:
Fixed In Version: 0.2.8-2.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1020825 (view as bug list)
Last Closed: 2013-11-21 18:00:24 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
yanwang: needinfo? (zkabelac)

Attachments (Terms of Use)
Correct metadata before corruption (1.97 KB, application/octet-stream)
2013-10-15 06:07 EDT, Zdenek Kabelac
no flags Details
Bad metadata with zeroed 40960 byte (1.96 KB, application/octet-stream)
2013-10-15 06:08 EDT, Zdenek Kabelac
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2013:1696 normal SHIPPED_LIVE device-mapper-persistent-data enhancement update 2013-11-20 16:52:12 EST

  None (edit)
Description Zdenek Kabelac 2013-10-15 06:06:14 EDT
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:

Actual results:

thin_check returns 0 for bad metadata
thin_repair is not fixing them

Expected results:

Additional info:
Comment 1 Zdenek Kabelac 2013-10-15 06:07:13 EDT
Created attachment 812413 [details]
Correct metadata before corruption
Comment 2 Zdenek Kabelac 2013-10-15 06:08:17 EDT
Created attachment 812414 [details]
Bad metadata with zeroed 40960 byte
Comment 4 Joe Thornber 2013-10-17 06:04:01 EDT
Yes, this is a serious bug.  A new upstream package has been released (v0.2.8).


The patches relevant to this bug are:


All other changes in the release are to do with the cache tools, and don't effect the thin tools binaries.

RHEL packages will be built today.
Comment 6 yanfu,wang 2013-10-17 22:58:19 EDT
qa_ack+ as per above comments.
Comment 17 errata-xmlrpc 2013-11-21 18:00:24 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.