Reclaim Zero Page on Thin Provisioning Storage
base on experience.
In this era of provisioning, we know several enterprise storage that provide Thin Provisioning or Dynamic Provisioning. In this case, I will write my experience with HDS VSP include with thin provisioining.
Base on explenation on wikipedia.org : In computing, thin provisioning involves using virtualization technology to give the appearance of having more physical resources than are actually available. If a system always has enough resource to simultaneously support all of the virtualized resources, then it is not thin provisioned. The term thin provisioning is applied to disk layer in this article, but could refer to an allocation scheme for any resource. For example, real memory in a computer is typically thin-provisioned to running tasks with some form of address translation technology doing the virtualization. Each task acts as if it has real memory allocated. The sum of the allocated virtual memory assigned to tasks typically exceeds the total of real memory.
The efficiency of thin or thick/fat provisioning is a function of the use case, not of the technology. Thick provisioning is typically more efficient when the amount of resource used very closely approximates to the amount of resource allocated. Thin provisioning offers more efficiency where the amount of resource used is much smaller than allocated, so that the benefit of providing only the resource needed exceeds the cost of the virtualization technology used.
Just-in-time allocation differs from thin provisioning. Most file systems back files just-in-time but are not thin provisioned. Overallocation also differs from thin provisioning; resources can be overallocated / oversubscribed without using virtualization technology, for example overselling seats on a flight without allocating actual seats at time of sale, avoiding having each consumer having a claim on a specific seat number.
Thin provisioning is a mechanism that applies to large-scale centralized computer disk-storage systems, SANs, and storage virtualization systems. Thin provisioning allows space to be easily allocated to servers, on a just-enough and just-in-time basis. Thin provisioning is called “sparse volumes” in some contexts.
Thin provisioning, in a shared-storage environment, provides a method for optimizing utilization of available storage. It relies on on-demand allocation of blocks of data versus the traditional method of allocating all the blocks up front. This methodology eliminates almost all whitespace which helps avoid the poor utilization rates, often as low as 10%, that occur in the traditional storage allocation method where large pools of storage capacity are allocated to individual servers but remain unused (not written to). This traditional model is often called “fat” or “thick” provisioning.
With thin provisioning, storage capacity utilization efficiency can be automatically driven up towards 100% with very little administrative overhead. Organizations can purchase less storage capacity up front, defer storage capacity upgrades in line with actual business usage, and save the operating costs (electricity and floorspace) associated with keeping unused disk capacity spinning.
Thin technology on a storage virtualization frame was first introduced by DataCore Software. Previous systems generally required large amounts of storage to be physically preallocated because of the complexity and impact of growing volume (LUN) space. Thin provisioning enables over-allocation or over-subscription.
Over-allocation or over-subscription is a mechanism that allows a server to view more storage capacity than has been physically reserved on the storage array itself. This allows flexibility in growth of storage volumes, without having to predict accurately how much a volume will grow. Instead, block growth becomes sequential. Physical storage capacity on the array is only dedicated when data is actually written by the application, not when the storage volume is initially allocated. The servers, and by extension the applications that reside on them, view a full size volume from the storage but the storage itself only allocates the blocks of data when they are written.
As a practical consideration, a storage manager needs to monitor actual storage used, adding additional storage capacity such as disks, tapes, solid-state drives (SSD), etc. as necessary to satisfy the write requests of the server and residing application(s).
Due to the new thin provisioing, as a storage manager or storage administrator, there is additional work that need to do. “Monitor Actual Storage Used”.
I have a case below, and hopefully it will help you to resolve your storage FAT issue and make it THIN. :)
I use Solaris Server, with Veritas Volume Manager. I found that used size on Veritas FS and Used size on Storage is different.
I configure 1 LUN or LDEV 10:00 on storage and assign into the server.
on Server side, I setup ldev 10:00 to be managed by veritas, and I create 1 volume oradata for that ldev. and then I mount under /ORADATA mountpoint.
After several days or weeks, I see FS /ORADATA used 50% only on server side but when I check on storage side trhough LDEV number 10:00 it was used 99%. How come ?
that’s the provisioning things….. need to do Reclaim Zero Page.
How to do that ? it’s simple, just need some workaround to make the FS full with create simple file and then remove the file. after that, we do Reclaim Zero Page from HDS VSP Storage Navigator. eazy as that.
Step by step
1. Open Storage Navigator, goes to POOL1 or others where LDEV 10:00 created and make sure the used is higher than what we see on OS side
2. Login to the server, and check FS stat specially /ORADATA using command df -h or others, make sure that used size of FS lower that used size on storage
3. Create dump file or zero file on /ORADATA fs with this command dd if=/dev/zero of=dump.file bs=1024000 count=10000, becareful on the BS and COUNT size, it will depend on free space of FS that available. you can modify the BS or COUNT base on your freespace.
4. to make the FS full maximum, create this dumpfile.full, with this command at /ORADATA filesystem. cat /dev/zero > dumpfile.full
5. After FS get full, some error pop up on Server side that tell no space left on the server and then please remove the file with RM command, #rm dump.file and #rm dumpfile.full
6. Next, we go to VSP storage navigator, goes to POOL1 or where LDEV 10:00 created, and then click More Action (right bottom), and then click reclaim zero page.
7. ahhhh….hhaaa….. used size on storage will be same with what we see on server.