A 2500x Efficiency Factor Highlights Differences Between Competing Thin Provisioning Solutions
This past summer a rather humorous video debate broke out on the StorageRap and RupturedMonkey.com blog sites. The debate centered on the 42 MB page size of Hitachi Data Systems (HDS) Dynamic Provisioning feature (HDS's implementation of thin provisioning) and the 16K block size of the 3PAR InServ Storage Server thin provisioning technology.
Marc Farley claimed in a StorageRap blog post that HDS's thin provisioning technology is terribly inefficient in its design. Rupturedmonkey.com's Nigel Poulton fired back by saying that Farley's claims did not paint a complete picture. While both Farley's and Poulton's videos generated a chuckle from me, the thin provisioning technology that they talk about and upon which users are betting their business is no laughing matter.
To briefly recap the exchange between Farley and Poulton, Farley posted a blog on his StorageRap website on June 25, 2009, that claimed the 42 MB page size of HDS's Dynamic Provisioning was hugely inefficient when compared to the 16K page sizes of 3PAR's Thin Built In™ design. Within hours after Farley's post, Poulton posted a comment on Farley's blog and then filmed and posted a two-part video blog on his own site that explained why HDS's 42 MB page size was really a better solution for enterprises than 3PAR's 16K page size.
Both of these individuals had good arguments as to why one thin provisioning solution was better than the other. Farley's illustration in his video of how HDS carved out a 42 MB page file for new writes from each application server struck a nerve with me. For instance, if you have four application servers and they each send a net new write to the HDS storage system, HDS using Dynamic Provisioning will consume over 160 MB of storage while the 3PAR InServ Storage Server would only consume 64K of storage (i.e. - 3PAR's approach is 2,500x more efficient than HDS's approach on the initial write).
However I had to respect Poulton's counterpoint in his blog that subsequent writes from any of those respective application servers would not consume any additional blocks of storage on the HDS array. Rather they would continue to write to that initial 42 MB block of allocated storage on the HDS storage system and would not consume another 42 MB of storage until that first 42 MB of storage is filled up.
In the case of 3PAR, it would continue to allocate new 16K blocks as additional writes from the same application server arrive. So while 3PAR is arguably more efficient in how it initially allocates storage, the major differences between how the 3PAR and HDS storage systems manage storage capacity appear to primarily surface during the initial write and then when it fills up. Theoretically it is only during those two times that HDS's Dynamic Provisioning becomes grossly inefficient.
However an assumption being made by Poulton in the case of HDS is that subsequent writes from the same application server to the HDS thinly provisioned storage volume are always made to the original or subsequent 42 MB block of storage. This is not a safe assumption.
One of the wildcards in implementing thin provisioning is the type of operating system and its associated file system that are used in conjunction with the thinly provisioned volume. Some file systems when they are created write metadata in 8 MB, 10 MB, 52 MB and other larger intervals up to about 128 MB on the thinly provisioned volume. File systems that do this include AIX JFS, HP-UX HFS, Linux XFS and Solaris UFS. (This is illustrated on a table that appears on page 30 of the August 2009 HP StorageWorks XP24000/XP20000 Thin Provisioning Software User's Guide. The HP StorageWorks XP24000/XP20000 is HP's version of the HDS USP.)
So how does this file system behavior impact 3PAR and HDS/HP? Like anything else, it depends. If users are connecting Windows 2003 or Windows 2008 servers to either of these storage systems, 3PAR will still thinly provision storage more efficiently than HDS/HP. While initial utilization differences may be small, they will pile up in 3PAR's favor as application server IO's initiate 16K capacity increments versus HDS' 42MB. In addition, recent thin-related announcements from 3PAR suggest it aims to offer a significant advantage going forward.
However enterprise organizations increasingly measure their storage utilization in the tens and even hundreds of TBs, especially among the larger enterprise environments where AIX, Solaris, Linux and HP-UX systems reside and for which 3PAR, HDS and HP are many times gunning. It is in these environments that the efficiency of 3PAR's thin provisioning technology indisputably overshadows HDS and HP when file systems are initialized.
3PAR can do nothing to stop the file system from writing metadata at specific intervals but it can and does mitigate the impact that these file systems have on a thinly provisioned volumes by only consuming 16K of physical capacity as these file system metadata writes occur. In the case of the HDS and HP systems, they can do nothing. They will consume another 42 MB of capacity and, as the table in the HP User Guide points out, the entire size of the thinly provisioned volume is in some cases consumed.
Right now storage providers of thin provisioning are having a good time taking pot shots at one another in regards to their implementations of thin provisioning but for users, thin provisioning is serious business as choosing the right (or wrong) implementation of thin provisioning directly impacts an organization's bottom line.
In this case of 3PAR versus HDS/HP, it becomes apparent that 3PAR's more efficient implementation of thin provisioning will use less storage in every circumstance. However users measure success in dollars and cents and not saved (or unsaved) storage capacity. In this respect, 3PAR's thin provisioning technology has the edge as data grows in Windows environments over HDS and HP. But when it comes to AIX, HP-UX, Linux and Solaris environments, 3PAR has a financial edge that is measurable and definitive from the very start.
Marc Farley claimed in a StorageRap blog post that HDS's thin provisioning technology is terribly inefficient in its design. Rupturedmonkey.com's Nigel Poulton fired back by saying that Farley's claims did not paint a complete picture. While both Farley's and Poulton's videos generated a chuckle from me, the thin provisioning technology that they talk about and upon which users are betting their business is no laughing matter.
To briefly recap the exchange between Farley and Poulton, Farley posted a blog on his StorageRap website on June 25, 2009, that claimed the 42 MB page size of HDS's Dynamic Provisioning was hugely inefficient when compared to the 16K page sizes of 3PAR's Thin Built In™ design. Within hours after Farley's post, Poulton posted a comment on Farley's blog and then filmed and posted a two-part video blog on his own site that explained why HDS's 42 MB page size was really a better solution for enterprises than 3PAR's 16K page size.
Both of these individuals had good arguments as to why one thin provisioning solution was better than the other. Farley's illustration in his video of how HDS carved out a 42 MB page file for new writes from each application server struck a nerve with me. For instance, if you have four application servers and they each send a net new write to the HDS storage system, HDS using Dynamic Provisioning will consume over 160 MB of storage while the 3PAR InServ Storage Server would only consume 64K of storage (i.e. - 3PAR's approach is 2,500x more efficient than HDS's approach on the initial write).
However I had to respect Poulton's counterpoint in his blog that subsequent writes from any of those respective application servers would not consume any additional blocks of storage on the HDS array. Rather they would continue to write to that initial 42 MB block of allocated storage on the HDS storage system and would not consume another 42 MB of storage until that first 42 MB of storage is filled up.
In the case of 3PAR, it would continue to allocate new 16K blocks as additional writes from the same application server arrive. So while 3PAR is arguably more efficient in how it initially allocates storage, the major differences between how the 3PAR and HDS storage systems manage storage capacity appear to primarily surface during the initial write and then when it fills up. Theoretically it is only during those two times that HDS's Dynamic Provisioning becomes grossly inefficient.
However an assumption being made by Poulton in the case of HDS is that subsequent writes from the same application server to the HDS thinly provisioned storage volume are always made to the original or subsequent 42 MB block of storage. This is not a safe assumption.
One of the wildcards in implementing thin provisioning is the type of operating system and its associated file system that are used in conjunction with the thinly provisioned volume. Some file systems when they are created write metadata in 8 MB, 10 MB, 52 MB and other larger intervals up to about 128 MB on the thinly provisioned volume. File systems that do this include AIX JFS, HP-UX HFS, Linux XFS and Solaris UFS. (This is illustrated on a table that appears on page 30 of the August 2009 HP StorageWorks XP24000/XP20000 Thin Provisioning Software User's Guide. The HP StorageWorks XP24000/XP20000 is HP's version of the HDS USP.)
So how does this file system behavior impact 3PAR and HDS/HP? Like anything else, it depends. If users are connecting Windows 2003 or Windows 2008 servers to either of these storage systems, 3PAR will still thinly provision storage more efficiently than HDS/HP. While initial utilization differences may be small, they will pile up in 3PAR's favor as application server IO's initiate 16K capacity increments versus HDS' 42MB. In addition, recent thin-related announcements from 3PAR suggest it aims to offer a significant advantage going forward.
However enterprise organizations increasingly measure their storage utilization in the tens and even hundreds of TBs, especially among the larger enterprise environments where AIX, Solaris, Linux and HP-UX systems reside and for which 3PAR, HDS and HP are many times gunning. It is in these environments that the efficiency of 3PAR's thin provisioning technology indisputably overshadows HDS and HP when file systems are initialized.
3PAR can do nothing to stop the file system from writing metadata at specific intervals but it can and does mitigate the impact that these file systems have on a thinly provisioned volumes by only consuming 16K of physical capacity as these file system metadata writes occur. In the case of the HDS and HP systems, they can do nothing. They will consume another 42 MB of capacity and, as the table in the HP User Guide points out, the entire size of the thinly provisioned volume is in some cases consumed.
Right now storage providers of thin provisioning are having a good time taking pot shots at one another in regards to their implementations of thin provisioning but for users, thin provisioning is serious business as choosing the right (or wrong) implementation of thin provisioning directly impacts an organization's bottom line.
In this case of 3PAR versus HDS/HP, it becomes apparent that 3PAR's more efficient implementation of thin provisioning will use less storage in every circumstance. However users measure success in dollars and cents and not saved (or unsaved) storage capacity. In this respect, 3PAR's thin provisioning technology has the edge as data grows in Windows environments over HDS and HP. But when it comes to AIX, HP-UX, Linux and Solaris environments, 3PAR has a financial edge that is measurable and definitive from the very start.
Newsletter Signup
Leave a comment