Bug 1089921
Summary: | There will be file lost in guest after do blockcommit when guest with non-cached qcow2 disk as source file | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Shanzhi Yu <shyu> | |
Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> | |
Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | 7.0 | CC: | acathrow, bili, chhu, dyuan, eblake, jdenemar, jmiao, juzhang, mzhan, shu | |
Target Milestone: | rc | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Bug Fix | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1089924 (view as bug list) | Environment: | ||
Last Closed: | 2014-04-23 12:01:20 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: | 1089924 |
Description
Shanzhi Yu
2014-04-22 09:00:26 UTC
By booting the domain from base.img in step 5, you made any image based on base.img completely useless (i.e., base.s3 and base.s4 contain just garbage). This is because booting from the image changes it (and in case of ext3 even mounting the image which was not cleanly unmounted read-only would change it too). (In reply to Jiri Denemark from comment #1) > By booting the domain from base.img in step 5, you made any image based on > base.img completely useless (i.e., base.s3 and base.s4 contain just > garbage). This is because booting from the image changes it (and in case of > ext3 even mounting the image which was not cleanly unmounted read-only would > change it too). Jiri, As your explaination, I can unsterstand step 6,7,8 is useless here. But, after commmit base.s2 to base.img, should base.img include file both s1 and s2? If not, what does blockcommit really did here? Visually, look at it this way, where XX represents a cluster that refers back to the parent file. Pre-commit, you have: base.img AA BB CC DD # Guest saw AA BB CC DD at this point base.s1 EE XX FF XX # Guest saw EE BB FF DD at this point base.s2 GG HH XX XX # Guest saw GG HH FF DD at this point After committing base.s2 into base.img, you have: base.img GG HH FF DD # base.img now contains all content from s1 and s2 base.s1 EE XX FF XX # Reading this image would see EE HH FF DD, but # that never happened - the image is now corrupt base.s2 GG HH XX XX # this would still read as GG HH FF DD, but since # it relies on corrupt base.s1, it's risky so after the commit, the best thing is to declare base.s1 and base.s2 as useless, and delete them. The point of commit is to shorten the chain by modifying the base image and discarding the snapshots that are now no longer needed now that the base image includes the same content. One other thing to be aware of - you took a --disk-only snapshot, but without requesting --quiesce. Reverting to that snapshot behaves the same as if you had pulled the power cord from a running machine. If the OS had not flushed the files to disk prior to when you yank the cord (aka the time when you took the disk snapshot), then changes you made to the filesystem prior to the snapshot may not appear after reverting to that state, because they had not yet been flushed. Remember that the state of the disk is often inconsistent (lags) in comparison to the state of the file system of a running system, where pulling the power cord abruptly may lose up to several seconds worth of changes as it rolls back to the last known safe journaling point that was actually recorded in the disk (this is intentional - if all file system operations waited for the disk to be consistent, your system would be much slower; the point of journaling filesystems is to cache in-flight file system changes for several seconds and only later catch the disk up to that state, so that a running system has better throughput, which works only as long as you can guarantee that power isn't yanked abruptly). You probably want to ensure that the guest does sync in between creating a file and taking the snapshot, and/or use the --quiesce flag when creating the snapshot, both in order to ensure that the state of the disk at the time of the snapshot actually contains enough file system state so that reverting to your snapshot will see the files that you are creating in between snapshots. |