persistence and transactions

[bigman]

I am curious to know how io to the vm's drive is handled by parallels.
Take a transacted operation inside the guest os (e.g. oracle under win xp).
Is there a chance that the transaction completes successfully inside the
guest os but writing the data in the hosts real drive fails afterwards?

To make it short. When an application inside a guest os relies on successfully
persisting state to the drive is this propagated directly to the real drive in the host os
(without cache involvement and a possible later failure).?

Of course I think.

If somebody has insights, please let me know,
bigman

 

[bbraun]

It does not appear to sync data in a reliable fashion. To test, I wrote a program that did fsync() and fdatasync() on a linux guest OS, and no corresponding fsync() was generated on the OSX host system.

It would indeed appear that a "reliable" write in a guest OS does not necessarily mean the data was written to the physical hard disk used by the host OS.

 

[Ynot]

In our harddrive emulation we support 'Flush cache' IDE command. When it arrives to our emulation we call fsync.

So, i have no idea why linux guest do not tell to HDD to flush it's cache.

 

[bbraun]

To reproduce my results, you can do:
sudo fs_usage Parallels

Then in a linux guest OS, I ran:
#include <stdlib.h>
#include <unistd.h>
#include <sys/fcntl.h>

int main(int argc, char *argv[])
{
int fd;
char buf[1024];

fd = open("/tmp/blah", O_RDWR);
write(fd, buf, sizeof(buf));
fsync(fd);
fdatasync(fd);
}

And I did not see any fsync() calls generated on the Mac OS X host system. To verify, I ran the same program (minus the fdatasync(), since OSX's fsync() does that too) on the Mac OS X host, with sudo fs_usage | grep a.out, and I did see an fsync() reported.

 

[bigman]

Please address this as a very severe issue. It would limit the use of Parallels
a lot. Could you at Parallels please provide more information on this topic. Can
you verify the test case from bbraun? is this a bug or intended behaviour?

thanks a lot,
bigman

 

[bbraun]

Another test is hdparm -f /dev/hda on the Linux guest OS, as this should cause the drive to flush it's cache, even if fsync() doesn't do that.

Additionally, it appears fsync() is not what is needed on Mac OS X to flush the drive cache, an fcntl(fd, F_FULLFSYNC) is required. fs_usage doesn't show fcntl() operations, so my above test won't actually show whether or not a sync has occurred. However, I did a ktrace of Parallels running the guest OS, and I don't see a fcntl(F_FULLFSYNC);