Re: writeback cache + h700 controller w/1gb nvcache, corruption on power loss

[Avi Kivity <avi@redhat.com>]

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