Bug 961139 - why is the --force flag required when restoring a corrupted thin pool volume?
why is the --force flag required when restoring a corrupted thin pool volume?
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2 (Show other bugs)
7.0
x86_64 Linux
low Severity low
: rc
: ---
Assigned To: LVM and device-mapper development team
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-08 17:56 EDT by Corey Marthaler
Modified: 2013-06-12 03:32 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-12 03:32:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Corey Marthaler 2013-05-08 17:56:14 EDT
Description of problem:

[root@qalvm-01 ~]# vgcfgrestore snapper_thinp
  Consider using option --force to restore Volume Group snapper_thinp with thin volumes.
  Restore failed.

[root@qalvm-01 ~]# vgcfgrestore --force snapper_thinp
  WARNING: Forced restore of Volume Group snapper_thinp with thin volumes.
  Restored volume group snapper_thinp

Version-Release number of selected component (if applicable):
3.8.0-0.40.el7.x86_64

lvm2-2.02.99-0.28.el7    BUILT: Fri May  3 09:12:57 CDT 2013
lvm2-libs-2.02.99-0.28.el7    BUILT: Fri May  3 09:12:57 CDT 2013
lvm2-cluster-2.02.99-0.28.el7    BUILT: Fri May  3 09:12:57 CDT 2013
device-mapper-1.02.78-0.28.el7    BUILT: Fri May  3 09:12:57 CDT 2013
device-mapper-libs-1.02.78-0.28.el7    BUILT: Fri May  3 09:12:57 CDT 2013
device-mapper-event-1.02.78-0.28.el7    BUILT: Fri May  3 09:12:57 CDT 2013
device-mapper-event-libs-1.02.78-0.28.el7    BUILT: Fri May  3 09:12:57 CDT 2013
cmirror-2.02.99-0.28.el7    BUILT: Fri May  3 09:12:57 CDT 2013


How reproducible:
Everytime
Comment 1 Zdenek Kabelac 2013-05-09 08:16:45 EDT
Current support for vgcfgrestore of metadata containing thin pools is very limited, and should be used very carefully.

Since we cannot guarantee, the user's restore will not destroy his pool metadata, we have put in some limited support, which requires usage of  '--force' and user should be really thinking more then twice before he will use this command.

If the restore is being done purely because of restore of some non-thin related LV - everything should go as normal restore. However for thin pool restore, we are missing tool, to do some analysis between kernel metadata and restore lvm2 metadata and think about what best we can do, to get both into reasonably matching state. So far there is no such support - thus we require to use '-f'.

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