Documentation: remove misleading paragraph in UG Sec 9.9

[Terry Ellison]

"With VirtualBox, this type of access is called “raw hard disk access”; it allows a guest operating system to access its virtual hard disk much more quickly than with disk images, since data does not have to pass through two file systems (the one in the guest and the one on the host)."

Please remove this statement in future editions of the User Guide. It is rubbish. The code path for raw access is pretty much the same as VDI access. In extreme circumstances if the host filesystem is badly fragmented then yes they can be some performance degradation from using VDIs, but in some circumstances they can also work faster. In general, it's pretty much comparable, so it is a mistake to "hard sell" raw hard disk access in this way.

[Klaus Espenlaub]

I beg to differ. It might be more or less the same code path in VirtualBox itself, but it's a very much different code path in the host operating systems - and this is what that paragraph clearly refers to. Filesystems do incur an overhead.

You're right that there are good filesystems are pretty negligible in that aspect, but that doesn't apply to all filesystems used on the platforms VirtualBox runs on. Also dynamically growing VDI/VMDK files suffer from fragmentation (both at the filesystem level and due to their internal block allocation) and thus can be the cause for degraded performance.

In the ideal case both can be almost the same, but in the extreme case dynamically growing VDI/VMDK files can be a performance hazard.

[Terry Ellison]

Certainly in the case of windows hosts any I/O to a VMDK goes through an almost identical mapping processes and ends up in the same module (fileio-win.cpp) doing cpp stdio (Readfile / Writefile) only to "\.\PartitionN" rather than some file on an NTFS file system. Unless the filesystem is totally shagged, there is no difference in physical I/O patterns on the HDD from a VDI that is pre-allocated or a dynamic one that has been largely initialised through (cp -a / xcopy) partition copy. So your emphasis is wrong. Yes, in the extreme case there can be performance degradation, but much of this could be avoided by trivial changes to the VB VDI allocation algos.

In the case of Linux/Ext3 hosted filesystems the issues are more complex, but there are reasonable parallels. As we move to Ext4 these issues should be largely mitigated.

I disagree with you closing the ticket. However, I accept your right to rubbish your own product so I won't reopen it.

[Frank Mehnert]

How do you know how much different Windows handles accesses to the special partition files? Reading/writing from/to that special file could make a big difference (file cache). And, in the case of using a VDI, how do you want to ensure that even with a linear initialization the blocks are written to the file system in a linear order? It is up to the OS in which order the blocks are written. And the OS might choose an order which is kind of sub-optimal for a certain guest. And you are writing about ext3/ext4 but Klaus wrote about any file system in general. As Klaus said, in general the performance is probably the same but there might be cases were writing directly to a partition might improve the performance.

And there is no need to offend us. Starting a defect with this is rubbish is quite rude IMHO.

[Terry Ellison]

Frank, this ticket isn't the place to have this debate. It certainly wasn't my intent to offend either you or Klaus, and I apologise if you were.

My point was that the current wording does your product a disservice, because if read literally it means that VirtualBox believes that users will always experience an material performance penalty by virtualising file systems with their product. This sentence in your UG unnecessarily and unfairly criticises your product. How would you describe it?

[Klaus Espenlaub]

To close this ticket in a more friendly style than it began with - there have been changes to this manual section. You'll have to wait for 1.7.0 to really see if this addresses your concerns, but I'm quite positive that it does.

Also never forget that any manual text has to focus on the big picture. Documenting each and every small detail would cause the document to explode in size and as a result would render it useless, in particular for beginners. Experts will always complain that there are certain aspects missing.