From: Bill Davidsen <davidsen@tmr.com>
To: Neil Brown <neilb@suse.de>
Cc: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>,
linux-raid@vger.kernel.org
Subject: Re: Building a new raid6 with bitmap does not clear bits during resync
Date: Mon, 12 Nov 2007 10:28:55 -0500 [thread overview]
Message-ID: <47387137.7000401@tmr.com> (raw)
In-Reply-To: <18231.62186.908021.981786@notabene.brown>
Neil Brown wrote:
> On Thursday November 8, brederlo@informatik.uni-tuebingen.de wrote:
>
>> Hi,
>>
>> I have created a new raid6:
>>
>> md0 : active raid6 sdb1[0] sdl1[5] sdj1[4] sdh1[3] sdf1[2] sdd1[1]
>> 6834868224 blocks level 6, 512k chunk, algorithm 2 [6/6] [UUUUUU]
>> [====>................] resync = 21.5% (368216964/1708717056) finish=448.5min speed=49808K/sec
>> bitmap: 204/204 pages [816KB], 4096KB chunk
>>
>> The raid is totally idle, not mounted and nothing.
>>
>> So why does the "bitmap: 204/204" not sink? I would expect it to clear
>> bits as it resyncs so it should count slowly down to 0. As a side
>> effect of the bitmap being all dirty the resync will restart from the
>> beginning when the system is hard reset. As you can imagine that is
>> pretty anoying.
>>
>> On the other hand on a clean shutdown it seems the bitmap gets updated
>> before stopping the array:
>>
>> md3 : active raid6 sdc1[0] sdm1[5] sdk1[4] sdi1[3] sdg1[2] sde1[1]
>> 6834868224 blocks level 6, 512k chunk, algorithm 2 [6/6] [UUUUUU]
>> [=======>.............] resync = 38.4% (656155264/1708717056) finish=17846.4min speed=982K/sec
>> bitmap: 187/204 pages [748KB], 4096KB chunk
>>
>> Consequently the rebuild did restart and is already further along.
>>
>>
>
> Thanks for the report.
>
>
>> Any ideas why that is so?
>>
>
> Yes. The following patch should explain (a bit tersely) why this was
> so, and should also fix it so it will no longer be so. Test reports
> always welcome.
>
> NeilBrown
>
> Status: ok
>
> Update md bitmap during resync.
>
> Currently and md array with a write-intent bitmap does not updated
> that bitmap to reflect successful partial resync. Rather the entire
> bitmap is updated when the resync completes.
>
> This is because there is no guarentee that resync requests will
> complete in order, and tracking each request individually is
> unnecessarily burdensome.
>
> However there is value in regularly updating the bitmap, so add code
> to periodically pause while all pending sync requests complete, then
> update the bitmap. Doing this only every few seconds (the same as the
> bitmap update time) does not notciable affect resync performance.
>
I wonder if a minimum time and minimum number of stripes would be
better. If a resync is going slowly because it's going over a slow link
to iSCSI, nbd, or a box of cheap drives fed off a single USB port, just
writing the updated bitmap may represent as much data as has been
resynced in the time slice.
Not a suggestion, but a request for your thoughts on that.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
next prev parent reply other threads:[~2007-11-12 15:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-08 16:56 Building a new raid6 with bitmap does not clear bits during resync Goswin von Brederlow
2007-11-12 6:30 ` Neil Brown
2007-11-12 15:28 ` Bill Davidsen [this message]
2007-11-12 22:22 ` Neil Brown
2007-11-14 15:33 ` Bill Davidsen
2007-11-18 16:52 ` Goswin von Brederlow
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=47387137.7000401@tmr.com \
--to=davidsen@tmr.com \
--cc=brederlo@informatik.uni-tuebingen.de \
--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).