The second half of the 2.6.37 merge window
The second half of the 2.6.37 merge window
Posted Nov 2, 2010 6:39 UTC (Tue) by bronson (subscriber, #4806)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
In theory, trim could be just as useful to loopback-mounted filesystems as it is to SSDs, no?
Posted Nov 2, 2010 7:24 UTC (Tue)
by slothrop (guest, #69834)
[Link] (3 responses)
Posted Nov 2, 2010 14:05 UTC (Tue)
by tardyp (guest, #58715)
[Link] (1 responses)
Posted Nov 2, 2010 16:51 UTC (Tue)
by butlerm (subscriber, #13312)
[Link]
Posted Nov 3, 2010 16:49 UTC (Wed)
by nix (subscriber, #2304)
[Link]
The second half of the 2.6.37 merge window
in virtualbox or qemu. Then you could issue the FITRIM
ioctl from the running guest and it would be intercepted
by these programs and acted upon accordingly.
The second half of the 2.6.37 merge window
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.
The second half of the 2.6.37 merge window
The second half of the 2.6.37 merge window