On 04/17/2012 11:41 AM, Stefan Hajnoczi wrote: > > The disk corruption experienced was indeed lost data -- an fsck was necessary for 4 of the guests to boot at all in RW mode, they first came up read only. In the case of one of the guests there was actually files data / data lost after fsck was manually run upon reboot/single user mode. In some cases these were config files, in other database indexes, etc. This one of the 4 guests with the most severe corruption was not usable and we had to revert to a backup and pull current data out of it as much as possible. > > Since you used QEMU -drive cache=writeback data loss is expected on > host power failure. cache=writeback uses the (volatile) host page > cache and therefore data may not have made it to the RAID controller > before power was lost. > > Guest file system recovery - either a quick journal replay or a > painful fsck - is also expected on host power failure. The file > systems are dirty since the guest stopped executing without cleanly > unmounting its file systems. If you use cache=none or > cache=directsync then you should get a quick journal replay and the > risk of a painful fsck should be reduced (most/all of the data will > have been preserved). Both cache=writeback and cache=none should result in journal replay if the guest is using barriers. If you're using ext4 and data=journal, you should expect no data loss. With the defaults you can expect to lost recently written data (quite a lot with data=writeback) but the filesystem structure itself should be fine. Even with cache=directsync you should expect some data loss as the guest may hold data in its own page cache. So something unexpected is happening. Which guests (by OS type) are failing? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
