Basic building block of Hitachi Thin Provisioning technology is PAGE. Actual physical space (as 42MB Pool pages) is only assigned to a DP volume by the HDP software from the connected HDP Pool as that volume’s logical space is written to over time. A volume does not have any Pool pages assigned to it when it is first created. Technically, it never does – the pages are “loaned out” from its connected Pool to that DP volume until the volume is reformatted and deleted. At that point all of that volume’s assigned pages are returned to their original slots (by releasing the pointers) in the Pool’s Free Page List.
Dynamic Mapping Table (DMT): All pool pages are managed by the HDP software in Dynamic Mapping Table (DMT) which resides in Control Memory. All metadata for the HDP Pools and their DP-VOLs is maintained in the DMT, which resides in the 12GB-14GB address space of Control Memory. For USPv, DMT resides in Shared Memory (Module #4).
Free page List is an element in DMT used to maintain all the 42MB pages of a pool. So basically when a pool is created, it is split into equal blocks of 42MB which is nothing but pool pages and all the page pointers are stored in DMT. Pools Free Page List is a table of pointers to all of the pages located on its set of pool volumes along with some status information. When a DP-VOL needs a new physical storage, the next available page from Free Page List is assigned.
Structure of Free Page List: It consists of a matrix of 128 columns by n rows of 42 MB pages.
Where n (number of rows) = Total pages the pool contains / 128.
Thus, the concept of thin provisioned capacity involves the page capacity actually assigned to a DP-VOL – which grows over time – and not the reported size of the volume from the host’s perspective.
Each DP-VOL has a table for keeping track of pointer to its assigned Pool pages.
The table consist details of:
1. All assigned pool pages.
2.Pointers to find them on Pool Volumes.
3.A lookup table of assigned physical pages to the server’s virtual address space (the LBA range of all the 512 byte blocks in that volume).
Once a Pool page is assigned to a DP-VOL, it remains there regardless of the state of the data written to blocks on that page. If all data that happens to reside on that page is deleted by the host file system, leaving the page “empty”, it remains under the ownership of that DP-VOL. Each page, once assigned to the volume, becomes a piece of the physical space under a specific LBA range for the server. Once allocated, the page assignment is permanent until that DP-VOL is reformatted and deleted. This reformatting deletes all data on all of that DP-VOL’s pages so that they are clean when returned to the Pool for reuse.
House Keeping Pages:
There are some Pages from each pool that are not available for assignment to DP-VOLs.
i. 2 pages (84MB system region) are reserved for each Pool Volume.
ii. 98 pages (4GB system region) in every HDP Pool are reserved to use for a disk mirror copy of the DMT in control memory. So there are 2 sets of DMT, each one in Control memory & HDP Pool itself.
Pool Pages Structure:
An individual 42MB page is laid down on a whole number of consecutive RAID stripes from a single Pool Volume. The Table below illustrates the relationship among different RAID levels, their various RAID stripe sizes, and the assignment of consecutive stripes to a single page.
|RAID Type||RAID Level||Data Disks||Raid Stripe Size(KB)||No. of RAID stripes per HDP Page|
For example, HDP Pool that is composed of several RAID5 (7D+1P) Pool Volumes (LDEVs).
Each LDEV has a formatted RAID stripe width of 3,584KB. This comes from two 256KB consecutive chunks per disk, with (effectively) seven data disks in the stripe (256+256 x 7).
Therefore, 12 (42MB ÷ 3,584KB) such RAID stripes from a single 7D+1P LDEV will be used to create a single 42MB Pool Page . In the case of a Pool consisting of RAID10 (2D+2D) Array Groups, each LDEV will provide 42 consecutive stripes for each 42MB Pool page.