linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Neil Brown <neilb@suse.de>
Cc: Justin Maggard <jmaggard10@gmail.com>, linux-raid@vger.kernel.org
Subject: Re: Sysfs update frequency
Date: Sat, 20 Mar 2010 12:48:28 -0400	[thread overview]
Message-ID: <4BA4FC5C.7060502@tmr.com> (raw)
In-Reply-To: <20100317085256.6caee9bb@notabene.brown>

Neil Brown wrote:
> On Tue, 16 Mar 2010 14:32:55 -0700
> Justin Maggard <jmaggard10@gmail.com> wrote:
>
>   
>> I've noticed on recent kernels that /sys/block/md?/md/sync_completed
>> seems to rarely get updated.  What is the expected update interval?
>> For me, it seems to only update about once every 6% or so during the
>> resync.  Of course, /proc/mdstat has the actual current progress.
>>     
>
> The expected update time is every 6% - actually 1/16 which is 6.25%.
>
> sync_completed includes a guarantee that all blocks before this point really
> have been processed.  The number in /proc/mdstat is less precise.  The much
> of the array has been resynced, but due to the possibility of out-of-order
> completion of writes they may not be a contiguous series of blocks.
>
>   
Couldn't you just track the outstanding writes by LBA (or similar) and 
report that the completion is one less than the lowest write still 
outstanding? Since you would only do it when the user requests it, I 
don't think the overhead of a list scan or similar would be a show 
stopper. Or is that approach too simplistic?

> Providing the guarantee (which is needed for externally-managed metadata)
> requires briefly stalling the resync, so I didn't want to do it more often.
> I could possibly make it time-bases instead of size-based though.
>   

Is perfect accuracy needed, just as long as you don't promise to have 
synced more than you have? Are you using barriers to be sure the data is 
all the way to the platter, or is your stall just "to the device" 
anyway? Like any snapshot of a dynamic process, by the time you get the 
information it's out of date in any case, so I think a "at least this 
much has moved to the device" value would serve.

-- 
Bill Davidsen <davidsen@tmr.com>
  "We can't solve today's problems by using the same thinking we
   used in creating them." - Einstein


  parent reply	other threads:[~2010-03-20 16:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-16 21:32 Sysfs update frequency Justin Maggard
2010-03-16 21:52 ` Neil Brown
2010-03-16 22:25   ` Justin Maggard
2010-03-16 23:03     ` Michael Evans
2010-03-20 16:48   ` Bill Davidsen [this message]
2010-03-23  3:22     ` Neil Brown
2010-03-24 19:49       ` Bill Davidsen

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=4BA4FC5C.7060502@tmr.com \
    --to=davidsen@tmr.com \
    --cc=jmaggard10@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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).