The second half of the 2.6.37 merge window
The second half of the 2.6.37 merge window
Posted Nov 2, 2010 14:05 UTC (Tue) by tardyp (guest, #58715)In reply to: The second half of the 2.6.37 merge window by slothrop
Parent article: The second half of the 2.6.37 merge window
Seems one of the dev of vbox was answering on this topic a while ago.
http://forums.virtualbox.org/viewtopic.php?f=9&t=1822...
"""
VD images files are typically mapped onto physical rotating media. These have high burst bandwidth but poor seek times (compared to SSD). The VDI format uses 2Mb pages for performance reasons. Dropping this to 4K to align it to the SDD driver technology would have a disastrous impact on real I/O performance (up to a factor of 10 slowdown say). Sorry, but this is a dumb idea.
"""
This was not wrong 1 year ago.. now, I'm doing desktop virtualization on ssd laptop. I dont want my virtualdisk to grow undefinitively. I dont want spinning disk optimizations.
http://forums.virtualbox.org/viewtopic.php?f=9&t=1822...
"""
VD images files are typically mapped onto physical rotating media. These have high burst bandwidth but poor seek times (compared to SSD). The VDI format uses 2Mb pages for performance reasons. Dropping this to 4K to align it to the SDD driver technology would have a disastrous impact on real I/O performance (up to a factor of 10 slowdown say). Sorry, but this is a dumb idea.
"""
This was not wrong 1 year ago.. now, I'm doing desktop virtualization on ssd laptop. I dont want my virtualdisk to grow undefinitively. I dont want spinning disk optimizations.
Posted Nov 2, 2010 16:51 UTC (Tue)
by butlerm (subscriber, #13312)
[Link]
The second half of the 2.6.37 merge window
Nothing stops clients from trimming free 2MB blocks using 4K block trim operations...