Well....at least a little bit more information about your situation would help...at least if you actually want to be helped...
Ciao, Andreas
I ended up handing the VM's files to a data recovery company
who managed to help me overnight. (Yes, that[/b] critical.)
In return I removed the details from my original posting.
The question I now have is whether Fusion (or other VMware
products) perform out-of-order reads/writes at the native FS
level (to improve performance). And, if so, what effect that is
having on the ordering constrains/assumptions of the guest's
FS. Basically, someone has said "this is why I'm not trusting
it with mission-critical data" when he heard about my mishap.
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.
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.
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.