linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Jody McIntyre <scjody@sun.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	linux-raid@vger.kernel.org, neilb@suse.de
Subject: Re: [PATCH] md: Track raid5/6 statistics
Date: Fri, 02 Oct 2009 13:51:28 -0400	[thread overview]
Message-ID: <4AC63DA0.3050406@tmr.com> (raw)
In-Reply-To: <20091002170121.GB22539@clouds>

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@tmr.com>
  Unintended results are the well-earned reward for incompetence.


      reply	other threads:[~2009-10-02 17:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-12 20:57 [PATCH] md: Track raid5/6 statistics Jody McIntyre
2009-03-14 17:07 ` Dan Williams
2009-05-06 20:05   ` Jody McIntyre
2009-05-07 16:30     ` Dan Williams
2009-05-11 13:36       ` Jody McIntyre
2009-05-13 13:10         ` Bill Davidsen
2009-10-02 17:01           ` Jody McIntyre
2009-10-02 17:51             ` Bill Davidsen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AC63DA0.3050406@tmr.com \
    --to=davidsen@tmr.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=scjody@sun.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).