2011-04-11 09:33 AM
Curious if anybody has seen this before and if it's something to be concerned with. Have a V3140 that is currently seeing a lot of H type CPs which are defined as a CP caused by high water mark; the amount of modified data in the filer's memory cache is high enough that it is ideal to start a CP to force it out to disk. The H CP is caused when the amount of modified data in the filer's cache exceeds a threshold called the high-water mark. It differs from the F CP, which is caused by consumption of the NVRAM. For example, a file delete operation requires almost no room in the NVRAM (the file handle of the file and the containing directory is logged) but may involve changing many files: the directory changes when we remove the entry; the inode file changes as we free the inode; metadata changes as we free the blocks in the deleted file. After performing a lot of these operations, the filer could easily hit the modified-data high water mark before the NVRAM is filled and need a CP from log full.
This is the first time I've encountered this many back to back. I'm going to attempt to see if they correlate in time with some performance issues being seen on several servers. Here's a a chunk of the sysstat from during that time with many more H CPs occuring after as well:
2011-04-13 01:40 PM
Back to back CP can be identified by B/b. H is because of higher watermark reached for dirty blocks.
Not all writes and written to NVRAM, centain workloads examples like snapmirror destination wites are not logged in NVRAM so it will not cause F (NVRAM log full) type CPs
2012-09-18 09:09 AM
H type CPs are completely normal and not an indication of any type of problem or the potential for any type of problem in the future. All H means here is "the platform and OS version that you are running has decided to take a CP to ensure memory is freed for further operations". That is a highly summarized version of the internals.
Otherwise, what Mr. Baijulal wrote is correct even if not completely relevant to your question. There are indeed some operations that are not logged in NVRAM, but none of those are from a client perspective or in any way impact the stability of a write (regardless of source) to the underlying disks.
NGS Staff Engineer, Performance