[linux-lvm] Repair thin pool
zkabelac at redhat.com
Fri Feb 5 15:17:38 UTC 2016
Dne 5.2.2016 v 12:44 M.H. Tsai napsal(a):
> 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)...
> I have experience in repairing many seriously corrupted thin pools. If
> the physical medium is okay, I think that most cases are repairable.
> I also wrote some extension to thin-provisioning-tools (not yet
> published. the code still need some refinement...), maybe it could
You should always repair data where you are sure they are not changing in
That's why --repair requires currently offline state of thin-pool.
It should do all 'swap' operations in proper order.
More information about the linux-lvm