Hi Stephen, Marc Farley from 3PAR here. Thanks for the love and yes we are making steps in the right direction. I agree that thin provisioning is still in the up and coming phase of it's technology life cycle.
As for the interacting with the other parts of the storage ecosystem, I think you'll see progress made along those lines in the not too distant future. Otherwise, Thin Provisioning is a terrific purpose-based technology. Its not the optimal solution for user-exposed storage as you wrote, but it is extremely useful for line of business applications and back end application processes where "wild end user behavior" is minimal. These are environments where data creation and growth are more systematic. I don't know why people wouldn't want to use it for those scenarios.
Pclifford
· 1 year ago
Hello 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 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
Nick Triantos
· 1 year ago
Similarly to Compellent's approach we've, NetApp, addressed space recovery via a Space Reclaimer process on Windows on May 2007 with the SnapDrive for Windows v5.0.
josh_909
· 12 months ago
One comment I have on this is that Compellent's 'Free Space Recovery' agent only work on RDMs. I have a large deployment of microsoft IIS servers that run VMFS on a Compellent SAN. I created them with thin provisioning in mind, but as time goes by, and data is written/deleted to my various volumes...I lose that provisioning, and am currently unable to reclaim that space.
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?
All Comments
As for the interacting with the other parts of the storage ecosystem, I think you'll see progress made along those lines in the not too distant future. Otherwise, Thin Provisioning is a terrific purpose-based technology. Its not the optimal solution for user-exposed storage as you wrote, but it is extremely useful for line of business applications and back end application processes where "wild end user behavior" is minimal. These are environments where data creation and growth are more systematic. I don't know why people wouldn't want to use it for those scenarios.
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
www.davenportgroup.com
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
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?