Now, I have read on a Datacore forum thread that when ESX writes to a VMFS volume, it does so plainly without altering data. I haven't verified this yet, but if it is indeed true, this could mean that zero detection could be of great benefit across various operating systems.

So does anyone know if using tools like 'sdelete' to write zeros to free space on a VMFS disk would show up as zeros in back-end storage?

Now, I have read on a Datacore forum thread that when ESX writes to a VMFS volume, it does so plainly without altering data. I haven't verified this yet, but if it is indeed true, this could mean that zero detection could be of great benefit across various operating systems.

So does anyone know if using tool like 'sdelete' to write zeroes to free space on a VMFS disk would show up as zeroes in back-end storage?

Thanks for the comment! You are correct – Compellent’s thin import is impressive (as is their overall architecture). And their free space recovery app is key to my second concern about recovering once-used space – when it’s run. In short, the app communicates to the array that space can be recovered (thinned?) in the only way possible currently – on command.

It’s such a tough issue to crack – how to convince thin-unaware applications like filesystems to communicate with thin-capable storage systems. The only real solution is revolution – a new tightly-coupled file system, volume manager, and storage service. Until we get there, though, I do hope Compellent and 3PAR and others keep trying to crack this uncrackable nut!

Stephen

Thanks for the comment! You are correct – Compellent’s thin import is impressive (as is their overall architecture). And their free space recovery app is key to my second concern about recovering once-used space – when it’s run. In short, the app communicates to the array that space can be recovered (thinned?) in the only way possible currently – on command.

It’s such a tough issue to crack – how to convince thin-unaware applications like filesystems to communicate with thin-capable storage systems. The only real solution is revolution – a new tightly-coupled file system, volume manager, and storage service. Until we get there, though, I do hope Compellent and 3PAR and others keep trying to crack this uncrackable nut!

Stephen

You mention two glaring issues with Thin Provisioning 1) the inability to make “thin” existing “fat” volumes and 2) runaway volumes consuming space that cannot be recovered. This is a limitation that exists for all vendors that I am aware of, said one – Compellent. Their implementation of Thin Provisioning (they call it Dynamic Capacity) does address both of these issues head on.

When you implement a Compellent Storage Center and bring volumes to the SAN, their implementation allows you to do a “thin import” which will take the existing volume from say an EMC SAN that is allocated at 500GB but only has 44GB of real data, and import that so that only 44GB of space is utilized. This has been operational with Compellent for quite some time.

The second issue is addressable in Windows applications on Compellent today. When space is deleted on a windows volume, you run a simple “clean up” application called “Free Space Recovery” and that deleted space is now completely deleted and reusable. They are working on the other O/S’s, but it has been working this way since early this year, and honestly, it simply works.

When I look at the market for Thin Provisioning, there are only two companies who get Thin Provisioning right – 3PAR and Compellent.

Thanks

Paul Clifford
Davenport Group
http://www.davenportgroup.com

You mention two glaring issues with Thin Provisioning 1) the inability to make “thin” existing “fat” volumes and 2) runaway volumes consuming space that cannot be recovered. This is a limitation that exists for all vendors that I am aware of, said one – Compellent. Their implementation of Thin Provisioning (they call it Dynamic Capacity) does address both of these issues head on.

When you implement a Compellent Storage Center and bring volumes to the SAN, their implementation allows you to do a “thin import” which will take the existing volume from say an EMC SAN that is allocated at 500GB but only has 44GB of real data, and import that so that only 44GB of space is utilized. This has been operational with Compellent for quite some time.

The second issue is addressable in Windows applications on Compellent today. When space is deleted on a windows volume, you run a simple “clean up” application called “Free Space Recovery” and that deleted space is now completely deleted and reusable. They are working on the other O/S’s, but it has been working this way since early this year, and honestly, it simply works.

When I look at the market for Thin Provisioning, there are only two companies who get Thin Provisioning right – 3PAR and Compellent.

Thanks

Paul Clifford
Davenport Group
http://www.davenportgroup.com