On Thu, Dec 10, 2009 at 8:54 AM, Robin Green <[email protected]> wrote:
> You don't need virtualisation to move the blocks around on the disk to get > better performance. This has already been implemented, e.g. there is some > Intel software for Windows that does this. However, such software wouldn't > work as expected for a virtual disk file, so it might still be useful to > reimplement the idea in VirtualBox. > I know that the old defrag program did this, but that was in the days when you could make a pot of coffee faster than you could load a spreadsheet. I didn't know that they had any recent software for this. Anyways, I think this would be a feature that would provide quite a competitive edge compared to other virtualizers. For server systems I think this would be less useful - they spend more of their time accessing data files while the server processes are always running. But for a desktop oriented system, a noticeable improvement could be seen. I still remember the day I moved from ext3 to reiserfs and boy was I mad. All that performance has been sitting on my hardware for years, but I never used it because I chose the wrong filesystem. It felt like I'd just purchased a brand new computer. Compiles were fast as lightning, OpenOffice was more reasonable, for a 1.6GHz computer, I thought I had more than doubled my speed. But I really do a lot more disk accesses than processing anyways. I've been thinking about it and I'm really not sure how one would keep track of an index to determine which sectors to move. I don't think it would be trivial, but I'm sure a programmer experienced with indexes would have some ideas. Obviously you would automatically expire index entries for sectors that are rarely used to keep the index trim. But the key to the index is not that it has to keep track of sector accesses, but accesses in relation to other sectors. Sounds daunting to me, but I'm certain the performance would be worthwhile. Does anyone know of a tool that can tell how many disk SEEKs are performed? Because that's what we're really talking about reducing. There would still be the same amount of data read. -Joseph
_______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev
