Bug 1079067
| Summary: | unable to restore pool _tmeta device from live thin_dump'ed file | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Corey Marthaler <cmarthal> |
| Component: | device-mapper-persistent-data | Assignee: | Joe Thornber <thornber> |
| Status: | CLOSED ERRATA | QA Contact: | Jakub Krysl <jkrysl> |
| Severity: | high | Docs Contact: | Joe Thornber <thornber> |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | agk, heinzm, jbrassow, jkrysl, lmiksik, lvm-team, msnitzer, prajnoha, prockai, thornber, zkabelac |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Fixed In Version: | device-mapper-persistent-data-0.7.3-1.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-04-10 13:15:56 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1469559 | ||
|
Description
Corey Marthaler
2014-03-20 21:56:29 UTC
This is related to (if not a dup of) bug 1023828 and bug 1038387. Using thin_dump on live metadata is not a supported usage - however it might be seen equal to using 'dd' on a device. In general lvm2/dm doesn't prohibit root user to shot himself - root could equally use commands like rm -rf /* or dd if=/dev/zero of=/dev/vg/pool_tmeta - so while we do not suggest to use this case at all (access of life metadata) - it might be a situation where 'some data' are better then 'no data' at all. So at this moment 'thin_dump' is able to open live _tmeta device (which is not being opened by the thin pool target in exclusive mode). In the future we would like to 'map' usage of thin_dump to automated internal snapshot of thin pool metadata (feature supported by thin_pool target). I guess it would be really useful if thin_dump would be able to detect that there could be a serious problem ahead when dumping live (and likely inconsistent) metadata and print bold WARNING to a user - but likely this operation will not be banned. I guess I've always always seen thin_dump as more of a read operation, and not at all like doing a "dd if=/dev/zero of=/dev/vg/pool_tmeta" or an "rm -rf *". I thought we used thin_dump to get the data off the meta device and use thin_repair to put the valid data back on. So, maybe it's just me who needs to change his outlook on how potent this tool is. (In reply to Corey Marthaler from comment #3) > I guess I've always always seen thin_dump as more of a read operation, and > not at all like doing a "dd if=/dev/zero of=/dev/vg/pool_tmeta" or an "rm > -rf *". I thought we used thin_dump to get the data off the meta device and > use thin_repair to put the valid data back on. So, maybe it's just me who > needs to change his outlook on how potent this tool is. The metadata is changing all the time in a live system, so any dump you made would likely be inconsistent as the kernel changed the metadata underneath thin_dump. However, there is support for taking a *metadata* snapshot and dumping this from the live device (see the --metadata-snap switch for thin_dump). Of course the metadata snap could well be out of date, so it's mainly useful for getting the mappings of devices that we know aren't changing (eg, a snap for backup). Perhaps thin_dump should warn if it was unable to open the device O_EXCL (unless it's doing a 'safe' dump from a metadata snap)? "on Linux 2.6 and later, O_EXCL can be used without O_CREAT if pathname refers to a block device. If the block device is in use by the system (e.g., mounted), open() fails with the error EBUSY." (In reply to Alasdair Kergon from comment #5) > Perhaps thin_dump should warn if it was unable to open the device O_EXCL > (unless it's doing a 'safe' dump from a metadata snap)? > > "on Linux 2.6 and > later, O_EXCL can be used without O_CREAT if pathname refers > to a block device. If the block device is in use by the > system (e.g., mounted), open() fails with the error EBUSY." thin_dump does now warn and won't run if it can't get O_EXCL. Fixed: syscall 'open' failed: Device or resource busy Note: you cannot run this tool with these options on live metadata. 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. https://access.redhat.com/errata/RHEA-2018:0776 |