Lors d’une séance de troubleshooting impliquant un petit tour d’esxtop, nous nous sommes aperçu que les stats VAAI d’un SSD attaché localement comportaient des valeurs non nulles. un check avec esxcli nous confirme la bizarrerie, les deux SSD attachés en SATA “supportent” certaines primitives VAAI :

Nous avons alors utiliser vmkfstools pour créer un vmdk eagerzeroedthick et constater l’offload de création de zero mais il semble que ce ne soit pas fonctionnel (ZERO_F) :

Par contre, le UNMAP (vmkfstools -y 99) semble bien fonctionner :

Nous profiterons du VMworld 2013 pour demander à Cormac Hogan si cela signifie qu’ESXi supporte le TRIM, entre autres…

Tags: , , ,

3 Responses to “SSD + VAAI = TRIM ?”

  1. Hi Raphael,

    what a coincidence! I am running an ESXi host on SSDs since a few days and was now researching on the issue of TRIM support in ESXi. I stumbled over the possible relationship to SCSI UNMAP feature and finally discovered the same than you: My SSDs support the VAAI Delete Status and I can run “vmkfstools -y” on them!

    Have you talked to Cormac about that, and did he confirm that this is indeed equivalent to TRIM?

    Thanks and best regards

  2. Hi Andreas,
    What a coincidence indeed! I didn’t spoke to Cormac about that, i keep that one for VMworld because i’m sure i would have some juicy details i won’t have by email or twitter :) Will you be there?

    I’m surprise no one else told about that BTW.

    I also got the idea to check what appends when you remove files in Windows 8 VM residing on SSD. Maybe the TRIM command is catch by the vmkernel ?!

  3. Hi Raphael,

    I thought you were talking about VMworld in San Francisco, but obviously you mean Barcelona. Yes, I will also be there!
    Maybe we can meet and together cross-examine Cormac ;-) ?!

    Regarding TRIM in VMs I’m pretty sure that this does not work. There is a VMware fling available to achieve space reclamation on disks that were thin provisioned at the storage array layer, see I’m not sure if it still works. And I don’t think that it will be useful with SSDs. If the guest unmaps a block on its virtual disk (e.g. NTFS) it will still be allocated to the VMDK file at the host (VMFS) level and cannot really be unmapped there. At the VMFS level you can only unmap/trim blocks that do not belong to an existing VMDK file.

    At least I think so. It’s hard and confusing to think through all the different layers of storage virtualization and abstraction …


Leave a Reply