The second half of the 2.6.37 merge window

Posted Nov 1, 2010 23:16 UTC (Mon) 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

Do you think this could be used to reduce the size of virtualbox'es variable size virtual disks?

The second half of the 2.6.37 merge window

Posted Nov 2, 2010 4:51 UTC (Tue) by slothrop (guest, #69834) [Link] (5 responses)

No. This is not about reducing sizes, its about telling
your SSD which blocks are not used by the filesystem currently,
so that they could be added to the internal list of available
blocks. This hopefully makes the SSD snappier and faster.

The second half of the 2.6.37 merge window

Posted Nov 2, 2010 6:39 UTC (Tue) by bronson (subscriber, #4806) [Link] (4 responses)

Right. And if you tell virtualbox which blocks on the virtual disk are no longer used, the backing file can be made more sparse.

In theory, trim could be just as useful to loopback-mounted filesystems as it is to SSDs, no?

The second half of the 2.6.37 merge window

Posted Nov 2, 2010 7:24 UTC (Tue) by slothrop (guest, #69834) [Link] (3 responses)

That's an interesting idea, but it needs to be implemented
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

Posted Nov 2, 2010 14:05 UTC (Tue) by tardyp (guest, #58715) [Link] (1 responses)

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.

The second half of the 2.6.37 merge window

Posted Nov 2, 2010 16:51 UTC (Tue) by butlerm (subscriber, #13312) [Link]

Nothing stops clients from trimming free 2MB blocks using 4K block trim operations...

The second half of the 2.6.37 merge window

Posted Nov 3, 2010 16:49 UTC (Wed) by nix (subscriber, #2304) [Link]

You'd also need a holepunch operation in the overlying filesystem, to be able to insert holes in the middle of an existing file.

The second half of the 2.6.37 merge window

Posted Nov 2, 2010 7:37 UTC (Tue) by mokki (subscriber, #33200) [Link]

I think so. When the virtual block device run by virtualbox/kvm detects the trim command it could punch a hole to the disk image, freeing disk space.

The xfs has an ioctl for punching holes to files. unfortunately a fallocate flag for deallocating space from 2007 has not been included in mainline.