[linux-lvm] Repair thin pool

[M.H. Tsai]

2016-02-05 23:17 GMT+08:00 Zdenek Kabelac <zkabelac at redhat.com>:
> Dne 5.2.2016 v 12:44 M.H. Tsai napsal(a):
>>
>> Hi,
>>
>> Seems that your steps are wrong.  You should run thin_repair before
>> swapping the pool metadata.
>
> Nope - actually they were correct.
>
>> Also, thin_restore is for XML(text) input, not for binary metadata
>> input, so it's normal to get segmentation fault...
>>
>> "lvconvert --repair ... " is a command wrapping "thin_repair +
>> swapping metadata"  into a single step.
>> If it doesn't work, then you might need to dump the metadata manually,
>> to check if there's serious corruption in mapping trees or not....
>> (I recommend to use the newest thin-provisioning-tools to get better
>> result)
>>
>> 1. active the pool metadata (It's okay if the command failed. We just
>> want to activate the hidden metadata LV)
>> lvchange -ay vgg1/pool_nas
>>
>> 2. dump the metadata, then checkout the output XML
>> thin_dump /dev/mapper/vgg1-pool_nas_tmeta -o thin_dump.xml -r
>
> Here is actually what goes wrong.
>
> You should not try to access 'life' metadata (unless you take thin-pool
> snapshot of them)
>
> So by using thin-dump on life changed volume you often get 'corruptions'
> listed which actually do not exist.
>
> That said - if your thin-pool got 'blocked' for whatever reason
> (deadlock?) - reading such data which cannot be changed anymore could
> provide the 'best' guess data you could get - so in some cases it depends on
> use-case
> (i.e. you disk is dying and it may not run at all after reboot)...
>
> You should always repair data where you are sure they are not changing in
> background.
>
> That's why --repair requires currently offline state of thin-pool.
> It should do all 'swap' operations in proper order.
>
> Zdenek

Yes, we should repair the metadata when the pool is offline, but LVM
cannot activate a hidden metadata LV. So the easiest way is activating
the entire pool. Maybe we need some option to force activate a hidden
volume, like "lvchange -ay vgg1/pool_nas_tmeta -ff". It's useful for
repairing metadata. Otherwise, we should use dmsetup to manually
create the device.

In my experience, if the metadata had serious problem, then the pool
device usually cannot be created, so the metadata is not accessed by
kernel... Just a coincidence.


Ming-Hung Tsai