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.
Glenn
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Chris Thompson Sent: Thursday, September 07, 2006 4:01 PM To: toasters@mathworks.com Cc: ecoli82@msn.com; etraitel@gmail.com Subject: Re: Snap status and wafl scan
Eyal Traitel writes:
Note that snap status is an advanced command so its output shouldn't necessarily cause you concerns...
Well, while we're talking about things wot mere mortals were not meant to wot of...
ec0li ecoli82@msn.com wrote:
When I check snap status, I see next to recent snapshots : (xxxx/xxxx remaining). Also, It seems that this is in fact the wafl scan process "snap create summary update"
The effect worrying me is somewhat different. After a snapshot is deleted the above state lasts only seconds, but there is then a much more extended period where "snap status" looks normal but "wafl scan status" shows e.g.
carina*> wafl scan status Volume CUS: Scan id Type of scan progress 1 active bitmap rearrangement fbn 3340 of 4461 w/ max_chain_len 3 925 container block reclamation block 382 of 4461
The "container block reclamation" scan lasts several minutes (and this is a volume & aggregate of only a few hundred GB), and while it's going on disc read activity is high and severely impacts the cache - at least, if you trust the "cache age" shown by sysstat, which I am not sure I do.
This is with ONTAP 7.1.1P1 (but similar effects observed in earlier 7.x's).