Jody McIntyre wrote:
I finally got around to looking at the load average code and thinking how it could be applied to tracking stripe cache usage, and unfortunately I don't have any great ideas. What's useful to know is: 1. The current stripe_cache_active value, which can be sampled by a script during heavy IO/resync/etc. This is already available. 2. How often (relative to the amount of IO) we've had to block waiting for a free stripe recently. The "recently" part is hard to define and and not implemented by current the current patch - it just reports the number of events since the array was started, but we can collect statistics from before and after a run and compare. 3. We've had a few customers using write-intent bitmaps lately, and our "bit delayed" counter (the number of stripes currently on bitmap_list) has been useful in assessing the impact of bitmaps / changes to bitmap chunk size. But it's not really a great measure of anything so I'm open to suggestions. I think "average amount of time an IO is delayed due to bitmaps" would be nice and probably not too hard to implement, but I'm worried about the performance impact of this. Also, there's still the open question of where we report these values other than /proc/mdstat and I'm really open to suggestions. If nobody has any ideas, we'll just continue to patch raid5.c ourselves to extend /proc/mdstat.
I would think in /sys would be a better place, anything which changes /proc/mdstat is likely to break some script, and therefore be less useful (and adoptable to mainline), where another file in /sys would be really unlikely to cause an issue. People tend to look at what is in known files, but ignore files which were not known at the time of script creation. It tends to a messy tree of files, but rarely breaks existing code.
-- Bill Davidsen <davidsen@xxxxxxx> Unintended results are the well-earned reward for incompetence. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
