Our FAS2240-2 has a volume that is growing for unexplained reasons. How can I determine what's using all the space and stop it without deleting the volume?
A week ago four VMware vm's that used the the volume locked up when it ran out of space. One vm was deleted to free up working space. Gradually over the next few days it kept growing, even though the vm's should not have been increasing in size. All vm's have since been moved to other volumes and volume snaps were deleted. While browsing the datastore from Vsphere the volume shows to be empty but OnCommand reports 97% used; 54GB available of 1.8TB.
The problematic volume has not been deleted because I'd like to know why it's behaving this way before deleting the evidence. The volume snaps were deleted two days ago. The volume snapshot detail in OnCommand reports about 1MB Cululative Total Size for each of the six snaps, but the volume reports 28GB available of 2TB.
You said the datastore on vmware shows them empty - are these NFS datastores or have you carved out luns in the volume and presented those as datastores? If you're using luns, and they still exist, that is what is taking the space.
Is the volume in question vol2? vol2 and vol5 have no space guarantee - so they will show as free space the lesser of the aggregate free space, and the difference between the vol size and vol used. Even if the other volumes are at 50% capacity, if they are volume guaranteed the entire size of the volume is considered "used" in the aggregate.
Please post a df of the volume in question, df -A of aggr0.
That's the problem. The aggregate only has 80G available, and because these volumes have no space guarantee, they can only utilize whatever space is left in the aggregate. Even though they are 1.8TB (virtual), there is only 80G left of physical space, so they report as much.
You can change the space guarantee (vol options vol2 guarantee volume) - but it won't work in your case, because the containing aggregate does not have enough space to cover the request.
You can reduce the size of the other volumes - that will free space in the aggregate. Then you can size the thin volumes appropriately and make them thick. All this of course depends on your needs and projected usage - I'm just saying that you CAN do this....
Now I know how to recover from this increasingly restrictive state. Thanks.
In your opinion is there a guideline as to how much aggr space should be left available, for growth? That must be different depending on whether think or thin volumes are in use, but maybe 20% would be a good starting point. Clearly I let it get too small due to not understanding how free space is calculated.
Is there any problem resizing smaller a volume that has VM's in it, or should they be empty during the resize operation?
I have resized NFS data stores live many times - both up and down - with no impact. I can't remember if a rescan is needed on VMWare - if it doesn't see the new size I'd recommend it.
NetApp has documentation on what percentage space should be left available in volumes and aggregates, based on WAFL and performance - I want to say it's in the 80-90% range. Personally I've run aggregates (and volumes) at 99% for extended periods and not really noticed any issues, but I'm sure there are people out there who would say otherwise - of course it depends on change rate, etc.. And yes, it depends on thick or thin provisioning, and how much data you actually expect to use. Thin provisioning always has made me a little uneasy because of the ability for a single app, user, or in your case VM to affect many others. But there are use cases where thin provisioning is great. It all depends....