You are correct - the reclamation is a new feature - introduced around 7.0 I believe.
Unsure what version of ONTAP the issue was being seen on, but there were some bugs related to that feature-set that were fixed in later versions - some bugs were related to its efficiency, while some were related to the timing (when the freed space was showing back up).
Glenn
-----Original Message----- From: Chris Thompson [mailto:cet1@cus.cam.ac.uk] Sent: Friday, September 08, 2006 12:07 PM To: toasters@mathworks.com Cc: Glenn Walker Subject: Re: Snap status and wafl scan
ggwalker@mindspring.com (Glenn Walker) writes:
Ok - those are other things than what I previously mentioned.
Active Bitmap rearrangement is normal - I believe it has been around since 6.5 (pretty sure it wasn't a flexvol thing, that was
'deswizzler'
scan). It's to keep memory 'pretty', if memory serves.
The container block reclamation is a scanner responsible for ferreting out blocks that have been freed and marking them as usable to the
system
(delayed free scanner\delayed freer working here). This too is
normal.
Just in case it wasn't clear, I did not mean to suggest that these things were not "normal", or that they had any implications for filing system integrity. It was the performance aspect of the "container block reclamation" scan that originally brought it to my attention: specifically that after our dumps had finished (and the associated snapshots thus deleted) disc I/O remained high and cache age very low for some time. I don't think ONTAP used to behave like that in 6.5.
By contrast the "active bitmap rearrangement" scan (which is always running: it just cycles around the block numbers indefinitely) has no bad effect on performance that I have ever noticed.