This is why Thin Provisioning s*cks

The answer lies in the SCSI protocol.  As you know, our SAN is just a really big SCSI drive, for all that the server knows. It doesn’t know that the SAN is off on the network, and that the iSCSI initiator intercepts commands to/from the OS and redirects them over to us.
Unfortunately, the is no ‘delete’ command in the SCSI protocol. The server changes the File Table on one of the blocks of storage we’ve set aside for it the blocks it no longer needs, effectively deleting the data. But it never actually sends us a command ‘delete block 346135.’
Since we’re block storage, we are agnostic to the data stored on our blocks of disk space. The volume could be NTFS, or VMDK, we don’t know. So we dutifully mark any used blocks as dirty, and that’s how they stay, until the volume is deleted, or the server again writes over that block.
The server has the file table. So it knows where the blocks are, and which are used or not. When it reports that only 25GB of the 100GB volume are in use, you can believe it. When we say that 75GB of the 100GB are dirty, then you can believe us that at some point in time, data was written to all 75GB of space.
If you need to recover some of that space, then you will need to move the data off, delete the volume, and create a new, smaller volume. It’s the only way to recover dirty, yet un-used, space.

Source :

Posted in Equallogic and tagged .


  1. Hi ARJAN, I haven’t really deep gone into this subject. Do you know if other iSCSI SAN’s handle this differently? Do you know if this is the case with only thin provisioned volumes or all volumes?


    • Michael,

      As far as I know not every SAN manufacturer has Thin Provisioning implemented ( yet ). But I don’t think they will have a better solution for this problem. As stated by Equallogic the problem lies at the SCSI layer. There is no communication between the operating system and the Equallogic when files / data are deleted. My worst experience with Thin Provisioning is that when Windows performs a defrag of the iSCSI target, the volume on the Equallogic SAN grows very hard. I just don’t use Thin Provisioning any more. Windows can expand any volume when you’re running out of disk space. ( With or without the help of Dell’s ExtPart utility ). Another advantage of not using Thin Provisioning is that I’m forcing my colleagues to think before making a backup on the same disk with the consequence that I’m losing precious SAN space that I only can reclaim when I delete the volume . ( Exchange defrag with eseutil for example makes large temporary files on the same disk ).

      There is no difference between Thin Provisioning volumes and regular volumes. In both cases there is no signal to the SAN that the data is deleted. Only when using Thin Provisioning volumes the “problem” comes to your attention. When using regular volumes you don’t care how much data you are using, because Equallogic already claimed the space from your “free resources”.
      Another tip is using SDelete from Sysinternals. It writes zero’s over every deleted file. It won’t reclaim your “lost space” on your Equallogic but it makes your VCB backup a lot smaller. ( VCB doesn’t sees that some files are deleted either. )

  2. Cool, thanks for clarifying. But its not really that thin provisioning sucks on equallogic so much as iSCSI itself doesn’t allow for a delete??

Leave a Reply