Bug 1019217 - Thin_check doesn't return error exit code for broken metadata [NEEDINFO]
Summary: Thin_check doesn't return error exit code for broken metadata
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: device-mapper-persistent-data
Version: 6.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 6.5
Assignee: Joe Thornber
QA Contact: yanfu,wang
Depends On:
Blocks: 1020825
TreeView+ depends on / blocked
Reported: 2013-10-15 10:06 UTC by Zdenek Kabelac
Modified: 2013-11-21 23:00 UTC (History)
9 users (show)

Fixed In Version: 0.2.8-2.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1020825 (view as bug list)
Last Closed: 2013-11-21 23:00:24 UTC
Target Upstream Version:
yanwang: needinfo? (zkabelac)

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

System 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 21:52:12 UTC

Description Zdenek Kabelac 2013-10-15 10:06:14 UTC
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 10:07:13 UTC
Created attachment 812413 [details]
Correct metadata before corruption

Comment 2 Zdenek Kabelac 2013-10-15 10:08:17 UTC
Created attachment 812414 [details]
Bad metadata with zeroed 40960 byte

Comment 4 Joe Thornber 2013-10-17 10:04:01 UTC
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-18 02:58:19 UTC
qa_ack+ as per above comments.

Comment 17 errata-xmlrpc 2013-11-21 23:00:24 UTC
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.