Steve,
This might be of help:
http://now.netapp.com/Knowledgebase/solutionarea.asp?id=ntapcs17113
There is also a mechanism (that you alluded to) called the delayed free scanner. There were some issues with this, but I believe they were resolved in 7.0.2 and newer (perhaps 7.1).
Opening a case with NetApp support would get you a bit farther than what I'm able to provide, sorry.
Glenn
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Stephen C. Losen Sent: Wednesday, July 05, 2006 5:23 PM To: toasters@mathworks.com Subject: lun destroy frees space very slowly ?
I have two flex vols in the same aggregate and I need to shrink one and grow the other. To shrink the first volume I destroyed two LUNs (500 GB each) that I don't need any more to free 1000 GB. But I'm afraid to shrink the volume because according to df the space has not been freed yet. As a matter of fact, after over an hour, df reports that I have only gotten back about 35 GB. The free space is still dribbling back. The CPU is about twice as busy as usual and there seems to be extra disk activity. But at this rate it may not even finish tomorrow.
Can anyone tell me what's going on here? Is the filer zeroing all the old LUN data blocks? I believe that I read somewhere that a filer recovers free disk blocks with a separate thread that runs at a low priority.
I have the luxury of time here, but what happens if you need to free a lot of space and move it to another volume or perhaps create a new LUN in a hurry?
This is DOT 7.0.1R1 and I checked "bugs online" but didn't find anything to indicate that this slow behavior is a bug.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support