Suggestion: Add option to have emulated hard disk report itself as an SSD, and support TRIM

[Donuts]

Add an option to have VirtualBox report the emulated hard disk as an SSD to the guest OS. (For ATA drives, word 217 of IDENTIFY DEVICE should be 1.)

Also support TRIM (for ATA, the DATA SET MANAGEMENT command with TRIM bit set). That would allow an SSD-aware guest to tell VirtualBox which sectors it no longer needs. Then VirtualBox could reuse those sectors in the VDI file when "new" sectors are written to. In other words, that would reduce the rate of growth of dynamically-expanding VDI files. (Reading back TRIMed sectors should return all 0 bytes.)

So SSD-aware guest OSes like Windows 7 would behave optimally, e.g. by not defragmenting/optimising the disk in the background. Even when the host VDI file is on a normal hard disk, that is a good idea. For dynamically-expanding VDI files, defragmenting/optimising disk layout by the guest has no beneficial effect, and causes VDI file size to increase unnecessarily. And any I/O scheduler behaviour in the guest to minimise seeks could be disabled.

More generally, it would be great if the user could specify certain properties of any emulated hard disk. Apart from reporting as an SSD, allow the user to set the logical and physical block sizes, and logical sector offset. See for example ​http://mkp.net/pubs/storage-topology.pdf and other documents at ​http://mkp.net/computing.html

That would be invaluable for testing purposes (not many people have real 4KB-sector drives to test with), but also has real-world uses. If the VDI file is on a drive with 4KB sectors, allowing the guest OS to know that would improve performance. More generally, it would make moving to and from physical media with non-512-byte sectors easy. (For example, DVD-RAM has 2048-byte logical sectors, 32768-byte physical. Some MO disks have 1024-, 2048- or 4096-byte sectors. Plasmon UDO disks have 8192-byte sectors.)

[Klaus Espenlaub]

We're well aware of the fact that there are infinite possibilities to improve VirtualBox. Some of your suggestions are so far from common use that the development time wouldn't result in an acceptable improvement for the average user. Feel free to contribute code.

Back to the ATA TRIM command: it's not really a good match for the properties of the usual disk image formats. VDI has a really large block size (1M by default), and all of it has to be empty to get reused. VMDK has a smaller buffer (64K), but again it has to be completely unused. VHD is even more extreme than VirtualBox, and has a 2M block size. So things look much less attractive if one looks at the actual details. ATA TRIM information would have to be collected over time, however the only image format which can do this out of the box is VHD, which for other reasons isn't all that efficient.

[Donuts]

Being able to have VirtualBox report the emulated disk as an SSD would in fact benefit most users (of Windows 7 and later guest OSes). As I mentioned, when using a dynamically-expanding VDI, that will reduce VDI size because the guest avoids doing disk-layout optimisations which actually worsen performance. (Where the guest thinks data is on disk does not correspond to the position in the VDI file. So defragmenting/optimising layout normally moves data further away.)

Leaving trim support aside, it should be a fairly small change as no actual changes to disk I/O code would be needed, just how the drive identifies itself.

Talking of trim support specifically... I guess you'd need to profile how Windows 7 issues trim commands to see whether it would be worthwhile. The largest amount of data addressable by a single trim is 32MB (65536 512-byte blocks). *If* Windows 7 issues "large" trim commands, when for example the user deletes a 700MB CD image file, then remembering which 1MB blocks have been trimmed would be beneficial. On the other hand, if it issues much smaller <1MB trims, this idea is probably a non-starter, like you say.

For remembering which 1MB blocks are free (i.e. read back as zero, can be reused for writes), a simple modification of the block pointers could be done. E.g. set bit 31 to indicate the block is free, with bits [30:0] being the pointer to it. Maximum VDI size would be limited to 2PB then, probably still enough for a while yet. :)

[Klaus Espenlaub]

Oh, I totally forgot about the fact that newly created VDI files have the data areas aligned to 4K boundaries as of 4.0.0... if necessary we could easily increase the alignment.

SSD support is implemented for IDE/SATA disks as of 4.1.0_BETA2. Windows 7 detects this and deactivates scheduled defragmentation. Of course I don't recommend running a beta version in a production environment.

[Hugo Ideler]

When the backend is a raw vmdk, this is particularly valuable.

[Donuts]

Has this suggestion been implemented in VirtualBox 4.2? If so I guess this ticket can be closed.

[aeichner]

Yes TRIM is supported as an experimental feature in VBox 4.2 for VDI images but you have to enable it manually with "VBoxManage storagetattach <VM name> --storagectl "SATA-Controller" --port <port number of disk image> --discard on". Closing this defect as there are other defects covering TRIM on raw disks, etc.