linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Igor M Podlesny <for.poige+lsr@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Hi! Strange issue with LSR -- bitmaps hadn't been used during 2 of 3 RAIDs resync
Date: Tue, 26 Jun 2012 16:18:46 +1000	[thread overview]
Message-ID: <20120626161846.08489b0a@notabene.brown> (raw)
In-Reply-To: <CA+sTkh7=QrRyq23g=NDjOPLBfJRw8NFaQCPJc1JoDRa893_9oA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]

On Wed, 20 Jun 2012 10:49:32 +0800 Igor M Podlesny <for.poige+lsr@gmail.com>
wrote:

> On 28 May 2012 12:03, Igor M Podlesny <for.poige+lsr@gmail.com> wrote:
> > On 28 May 2012 10:54, NeilBrown <neilb@suse.de> wrote:
> > [...]
> >> The best indicator is total time that it takes (which can probably be
> >> extracted from logs as start and end are logged).  Divide that into size of a
> >> device to get average MB/sec.  If the bitmap was used, that will normally be
> >> much less the best throughput of the device.
> >
> >   That's exactly why I am stating it didn't use WIBs 2 times of 3. It
> > went resyncing from beginning till the end -- I had my finger on its
> > pulse. :)
> >
> >   I can't promise (due to popular "lack of time" disease, yeah), but
> > if I'll get on it using VirtualBox or real environment [Lord forbid
> > :)] once again, I'll let you know, sure.
> 
>    Here it is: http://pastie.org/4118133

This doesn't appear to show the "start to end" that I suggested, just 10% to
30%, but it does suggest that the bitmap isn't speeding things up at all, at
least for that part of the array... That is assuming you are talking about
md124.  I note that md125 doesn't have a bitmap.  Is that what you are
referring to?

The next thing to do would be to look at the bitmap immediately after reboot
to see how many bits are set.  Maybe lots are set for some reason.

> 
>    — 3.4.2-rt10 went suspend ok for 2 times, the 3rd it didn't.
> Reboot, resync, no bitmaps use.
> 
>    And, BTW, it's rather slow in despite of having max. stripe_cache_size set.
> 

A larger stripe cache isn't going to affect resync speed much (I think).
50MB/sec on each drive seems fairly good to me.  What were you expecting?

NeilBrown



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2012-06-26  6:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-27 11:32 Hi! Strange issue with LSR -- bitmaps hadn't been used during 2 of 3 RAIDs resync Igor M Podlesny
2012-05-27 12:00 ` NeilBrown
2012-05-27 16:10   ` Igor M Podlesny
2012-05-28  1:45     ` NeilBrown
2012-05-28  2:37       ` Igor M Podlesny
2012-05-28  2:54         ` NeilBrown
2012-05-28  4:03           ` Igor M Podlesny
2012-06-20  2:49             ` Igor M Podlesny
2012-06-26  6:18               ` NeilBrown [this message]
2012-06-26  8:55                 ` Igor M Podlesny
2012-06-26  9:22                   ` Igor M Podlesny

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=20120626161846.08489b0a@notabene.brown \
    --to=neilb@suse.de \
    --cc=for.poige+lsr@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    /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).