My guess would be that the default settings can
reorder reads/writes because by default, we go
through OS X's unified buffer cache to improve guest
performance. You can disable this under VMware Fusion
Preferences > Performance > Optimize for Mac OS
application performance. I don't know if Fusion
itself reorders reads/writes, I suspect not.
Can you be more specific?
I think what I am looking for is a guarantee that writes
to the guest FS are committed to the host disk (that is,
the raw partition in case of VMs that use physical disks,
or the host disk in case of VMs that use virtual disks) be-
fore the guest is permitted to continue. You know, as in
disabling write-back caching on actual disk drives.
That way a guest with a journaling FS wouldn't corrupt
even if the host (SW or HW) dies for some reason.
Fwiw, this is what happened to me. I was resizing some
guest partition, which held a journaling FS, when all the
sudden the host (SW i.e. Fusion) died. The result was a
corrupted guest FS: the repartitioning program relied on
atomic, properly ordered disk I/O -- which it did not get.
The loss spanned the clusters that were being moved at
that particular moment in time, which means that I did
lose whatever files were held by those clusters.
Luckily the rest of the FS was intact. This allowed a data
recovery company to "get nearly everything". Combining
their results with my most recent file-level backup then
allowed me to make a nearly perfect (though costly from
both a time and money standpoint) recovery.
On the other hand, I would also expect that
read/write reordering should be transparent to the
guest, since it should see cached versions - the only
time it would matter is if you had a power failure
and the buffers didn't get a chance to be flushed to
disk.
...which is what I am paranoid about. In a non-VM case,
all I have to do is use a journaling FS and disable write-
back disk caching. I want to get to that level of "safety"
for the VM case.
