All of lore.kernel.org
 help / color / mirror / Atom feed
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: Wed, 14 Nov 2007 10:33:40 -0500	[thread overview]
Message-ID: <473B1554.2050608@tmr.com> (raw)
In-Reply-To: <18232.53770.923521.968923@notabene.brown>

Neil Brown wrote:
> On Monday November 12, davidsen@tmr.com wrote:
>   
>> Neil Brown wrote:
>>     
>>> 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.
>>     
>
> Thanks for your thoughts.
> Choosing how often to update the bitmap during a sync is certainly not
> trivial.   In different situations, different requirements might rule.
>
> I chose to base it on time, and particularly on the time we already
> have for "how soon to write back clean bits to the bitmap" because it
> is fairly easy to users to understand the implications (if I set the
> time to 30 seconds, then I might have to repeat 30second of resync)
> and it is already configurable (via the "--delay" option to --create
> --bitmap).
>   

Sounds right, that part of it is pretty user friendly.
> Presumably if someone has a very slow system and wanted to use
> bitmaps, they would set --delay relatively large to reduce the cost
> and still provide significant benefits.  This would effect both normal
> clean-bit writeback and during-resync clean-bit-writeback.
>
> Hope that clarifies my approach.
>   

Easy to implement and understand is always a strong point, and a user 
can make an informed decision. Thanks for the discussion.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979


  reply	other threads:[~2007-11-14 15:33 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
2007-11-12 22:22     ` Neil Brown
2007-11-14 15:33       ` Bill Davidsen [this message]
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=473B1554.2050608@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.