I currently have 3 luns in a dynamic pool, all luns are shared to a Windows server via iSCSI. One of the mounted luns contained 20GB of data which has now been moved off to another system, however the HDS Navigator displays that the lun in question is using 40GB of the available space. I have also noticed that other luns are not registering data that I has moved or deleted. Is this a problem, or will this whitespace be automatically reclaimed when total disk space reaches a certain threshold?
How was the data moved? When you delete a file in windows, the file is not actually deleted from the disk. The delete command simply removes the record from the MFT thats points the file to its location on disk. Windows then knows that space is unused and therefore canbe overwritten. If you've just simply copied and moved the files off the drive, they will still be there just not visible in windows. Hence why you are seeing the capacity as still be allocated in Storage Navigator!
Thanks for the reply cris, this makes sense. So the only way to reclaim space is to format the LU using the Navigator.
that or you can delete the LUN, When you delete the LUN, the microcode will release and format all the blocks that LUN owned.
Remember these are destructive processes, so make 100% sure you don't need the data before proceeding.
also, even if Windows zeros those blocks out when data is deleted and so actually gets rid of the old data, the array won't automatically reclaim the allocated pages back to the pool. Once the pages have been given to a LUN, thats it. Unless you run a zero page reclaim which is a manual operation on a per LUN basis.
Hi Cris, not a huge concern at the moment but thanks for the software recommendation.
Bit confused actually. I have just created a 450GB LUN and mapped it to an RHEL box. Created an ext3 partition using all the space available.
I have not used the new parttion yet, available space on Linux shows as 420GB (5% reserved), but on the storage navigator it says 133GB consumed. What causes this to happen?
This will be due to the way different filesystems write across disks - some are more "thin-friendly" than others.
ext3 writes its meta-data in 128MB intervals (by default) across the entire disk. So for every block of meta-data (every 128MB along the disk) the array will allocate a 32MB DP-Pool page. This means that about 25% of your LUN will be allocated from the pool straight away. In your case ~112GB. I would guess formatting and other meta-data at the beginning of the disk would account for the extra space used taking it up to 133GB.
Take a look at this [url="http://www.hds.com/assets/pdf/hitachi-dynamic-provisioning-lessons-learned.pdf"]doc[/url]. Particularly pages 24 and 25.