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).
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.
-
Chris Thompson -
Glenn Walker