another thing we do is some kind of Defrag of the virtual disk files, not sure how effective it is. The idea is to re-arrange blocks with vhd file so sectors are sorted by their absolute disk offsets (not the logical offsets within the disk file). this way, for at least sequential virtual disk access, disk heads will move to the same direction, without going back and forth.
--- On Wed, 5/18/11, Huihong Luo <[email protected]> wrote: From: Huihong Luo <[email protected]> Subject: [vbox-dev] Fw: Re: some suggestions to improve vhd disks To: "VirtualBox developer's list" <[email protected]> Date: Wednesday, May 18, 2011, 11:05 PM --- On Wed, 5/18/11, Huihong Luo <[email protected]> wrote: From: Huihong Luo <[email protected]> Subject: Re: [vbox-dev] some suggestions to improve vhd disks To: "Howard Su" <[email protected]> Date: Wednesday, May 18, 2011, 11:03 PM our code is highly tighed with windows kernel driver code, very hard to separate. Will try in the future. As you know, Windows IRP is very different beast, the VHD driver itself is more than 50,000 line of code, with lots of optimizations, close to real hd, as we measure vbooted Windows 7 (from VHD) versus booted from real hd. So I'd rather provide some general ideas, and vbox team can improve the implementations. Disk code in vbox is already very fast. --- On Wed, 5/18/11, Howard Su <[email protected]> wrote: From: Howard Su <[email protected]> Subject: Re: [vbox-dev] some suggestions to improve vhd disks To: "Huihong Luo" <[email protected]> Date: Wednesday, May 18, 2011, 9:49 PM On Thu, May 19, 2011 at 3:43 AM, Huihong Luo <[email protected]> wrote: Compared to vdi/vmdk, vhd disk could be 2 x slower with current implementations. For example, when I dump a 250G disk to a vhd, it taks almost 2 x time to complete compared to vmdk. The following are some suggestions that could improve the performance, as we have implemented them in our kernel vboot driver for vhd (we didn't use any vhd code from vbox for vhd disk). (1) allocated a bitmap to keep tracking of all blocks, if a block has a sector bitmap of all 1s, then market it inside this block bitmap. This way, no need to read the sector bitmap for a block with all sectors allocated. (2) caching sector bitmaps. We cache 256 sector bitmaps, this saves the time to read and update sector bitmaps. Interesting ideas. Can you show you diff? These 2 can gain quite some performance, close to vmdk/vdi, at least. - huihong _______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev -- -Howard -----Inline Attachment Follows----- _______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev
_______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev
