ludloff
Contributor
Contributor

INACCESSIBLE_BOOT_DEVICE 0x0000007B (0x81893770,0xC0000102,0,0)

Smiley Sad

0 Kudos
4 Replies
Andreas_Masur
Expert
Expert

Well....at least a little bit more information about your situation would help...at least if you actually want to be helped... Smiley Wink

Ciao, Andreas

0 Kudos
ludloff
Contributor
Contributor

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.

0 Kudos
admin
Immortal
Immortal

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.

0 Kudos
ludloff
Contributor
Contributor

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.

0 Kudos