[vbox-dev] is virtstor being implemented?

[Huihong Luo]

yes, it's the speed reason. In theory, virtstor is supposed to be fast. However, since vbox is already doing so well on disk, I am not sure how much further can be improved.
 
In theory, virtstor bypasses many calls, and goes directly to the cheese, i.e., block i/o data transfer. The performance depends how well the mechanism for the transfer between vm and host, which is why I mentioned share folders. (btw, I know the difference between file sysem and block driver, I do that for a living). What I mean is that we can use the same large data transfer mechanism if shared folder's performance is very good. 
 
for example, a user app wants to write 10k data to the disk, it goes to the virtio driver after  a few calls in windows, if the virtstor driver can efficiently (directly) transfer the buffer to the host, perhaps through memory sharing, or pinned physical pages, this should improve the performance.
 
About the guest drivers, windows 7 and vista sp1 introduced some new models that should be even faster than kvm's implementation.

--- On Mon, 10/18/10, Liang Suilong <liangsuilong at gmail.com> wrote:


From: Liang Suilong <liangsuilong at gmail.com>
Subject: Re: [vbox-dev] is virtstor being implemented?
To: "Alexey Eromenko" <al4321 at gmail.com>
Cc: vbox-dev at virtualbox.org
Date: Monday, October 18, 2010, 10:21 PM


Virtio-blk is good at a lot of small files. If you need to read or write a lot of small files, virtio-blk has lower latency and a little better performance comparing with SATA port. Virtio-blk can decrease CPU usage. 


[non-related] Has drag-n-drop and copy-n-paste done? I am waiting for it. I think these two features will be kller features in the next major version of VirtualBox. 


On Tue, Oct 19, 2010 at 12:53 PM, Alexey Eromenko <al4321 at gmail.com> wrote:




On Tue, Oct 19, 2010 at 3:56 AM, Huihong Luo <huisinro at yahoo.com> wrote:
>
> I know the virtio for network is implemented in vbox, are there any plans implementing that for storage?
>
> If not, I can contribute to this, as we are very familiar with virtua disk stuff, as we do in our VBoot technology, which boots a real pc using a virtual disk, and it's close to native performance.
>
> What I am thinking is to use a virtual PCI device, and provide guest drivers. The PCI needs to be very performing in passing disk blocks.
>
> Not sure if current shared folder implementation is good enough, if so, we can easily pass the read/write using the current shared folder service to read/write the virtual disk file.
>
> - Huihong
>

1. So far there is no clear evidence that VirtIO-blk is any faster
than emulated SCSI controller.
The reason to implement it is speed ?

2. Windows-guest drivers exist (binary+source code)
http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/

So regarding drivers, the maximum effort needed is to WHQL them (along
with other VBox drivers).

3. Current Shared Folders is a FileSystem.
Making a block device out of it may not work, because how will it
sync, if the host updated files ? (guest assumes that a block-device
is a wholly-owned disk)
How can it work?

4. [non-related] We would _really_ like to see you contribute
drag-n-drop code, so this can be tested and released with the next
major version of VirtualBox.

--
-Alexey Eromenko "Technologov"

_______________________________________________
vbox-dev mailing list
vbox-dev at virtualbox.org
http://vbox.innotek.de/mailman/listinfo/vbox-dev



-- 
Fedora && Debian User, former Ubuntu User
My Page: http://www.liangsuilong.info
Fedora Project Contributor -- Packager && Ambassador
https://fedoraproject.org/wiki/User:Liangsuilong

-----Inline Attachment Follows-----


_______________________________________________
vbox-dev mailing list
vbox-dev at virtualbox.org
http://vbox.innotek.de/mailman/listinfo/vbox-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20101018/5a5d7902/attachment.html>