On 03/17/2010 10:14 AM, Chris Webb wrote:
Anthony Liguori<anthony@xxxxxxxxxxxxx> writes:
This really gets down to your definition of "safe" behaviour. As it
stands, if you suffer a power outage, it may lead to guest
corruption.
While we are correct in advertising a write-cache, write-caches are
volatile and should a drive lose power, it could lead to data
corruption. Enterprise disks tend to have battery backed write
caches to prevent this.
In the set up you're emulating, the host is acting as a giant write
cache. Should your host fail, you can get data corruption.
Hi Anthony. I suspected my post might spark an interesting discussion!
Before considering anything like this, we did quite a bit of testing with
OSes in qemu-kvm guests running filesystem-intensive work, using an ipmitool
power off to kill the host. I didn't manage to corrupt any ext3, ext4 or
NTFS filesystems despite these efforts.
Is your claim here that:-
(a) qemu doesn't emulate a disk write cache correctly; or
(b) operating systems are inherently unsafe running on top of a disk with
a write-cache; or
(c) installations that are already broken and lose data with a physical
drive with a write-cache can lose much more in this case because the
write cache is much bigger?
This is the closest to the most accurate.
It basically boils down to this: most enterprises use a disks with
battery backed write caches. Having the host act as a giant write cache
means that you can lose data.
I agree that a well behaved file system will not become corrupt, but my
contention is that for many types of applications, data lose ==
corruption and not all file systems are well behaved. And it's
certainly valid to argue about whether common filesystems are "broken"
but from a purely pragmatic perspective, this is going to be the case.
Regards,
Anthony Liguori
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>