From: NeilBrown <neilb@suse.de>
To: Robin Dong <robin.k.dong@gmail.com>
Cc: robin@robinhill.me.uk, linux-raid@vger.kernel.org, Tao Ma <tm@tao.ma>
Subject: Re: Question about resync in RAID5
Date: Mon, 22 Apr 2013 10:15:52 +1000 [thread overview]
Message-ID: <20130422101552.4eed452c@notabene.brown> (raw)
In-Reply-To: <CANsebLH0PcjV2nmcQ0TmEE_8XxF6pi53baSenV3qKwdRxioK+Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2595 bytes --]
On Wed, 17 Apr 2013 12:29:07 +0800 Robin Dong <robin.k.dong@gmail.com> wrote:
> 2013/4/17 Robin Hill <robin@robinhill.me.uk>
> >
> > On Tue Apr 16, 2013 at 05:46:07PM +0200, Roy Sigurd Karlsbakk wrote:
> >
> > > > > Is there any method to just resync WRITTEN data to new-added-disk ?
> > > > > Or any developing plan to add this feature?
> > > >
> > > > No, because md is a block device it has no knowledge of what data has
> > > > actually been written to the disk or where it is stored. This means it
> > > > has to rebuild the entire disk.
> > > >
> > > > There are plans to improve this by keeping track of which stripes have
> > > > been written to, which should help (and will also mean no need for an
> > > > initial RAID sync). I don't know whether this has progressed beyond
> > > > the idea stage yet though.
> > >
> > > Interesting - do you have any docs about this? I haven't seen any talk
> > > on this list about it...
> > >
> > It's from Neil's 2011 MD/RAID roadmap:
> > http://neil.brown.name/blog/20110216044002
> >
> > The basic idea was mentioned in a 2009 roadmap as well, but is a lot
> > more fleshed out in the above one.
>
>
> Hi, Neil
>
> Has anyone began to develope non-sync-bitmap feature? If not, I want to
> take a chance.
> Will the non-sync-bitmap be built on the write-intent-bitmap or I need to
> create a new bitmap in 'array state info' of v1.x metadata?
>
Hi Robin et al,
No, no implementation has been started.
You cannot use the same bits as the write intent bitmap as they mean
something different. But you could possibly use the same storage space.
i.e. have an alternate style of bitmap where there are two bits per 'chunk'.
One bit maps "this was written recently, a resync might be needed after a
crash" and the other means "This has been written since array create, so the
chunk needs to be recovered to any spare".
I don't know if this is the best approach - I haven't really thought about it
much.
There are several parts to this:
1/ decide how to store the new bitmap on disk, and implement that
2/ decide how to store the new bitmap in memory and implement that.
It might be the same...
3/ Set a bit in the new bitmap on each write (if it isn't set), and
trigger a resync of that chunk.
4/ Update the recovery process for each level to honour this new bit
5/ Allow "discard" operations to clear these bits.
If you do proceed with this, feel free to post a more concrete design before
proceeding to code - or just post code if you prefer.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2013-04-22 0:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-16 10:02 Question about resync in RAID5 Robin Dong
2013-04-16 10:24 ` Robin Hill
2013-04-16 15:46 ` Roy Sigurd Karlsbakk
2013-04-16 16:55 ` Robin Hill
[not found] ` <CANsebLH0PcjV2nmcQ0TmEE_8XxF6pi53baSenV3qKwdRxioK+Q@mail.gmail.com>
2013-04-22 0:15 ` NeilBrown [this message]
2013-04-22 9:16 ` Goswin von Brederlow
-- strict thread matches above, loose matches on Subject: below --
2013-04-16 9:59 Robin Dong
2013-04-15 20:27 ` Oliver Schinagl
2013-04-16 15:20 ` Keith Keller
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=20130422101552.4eed452c@notabene.brown \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
--cc=robin.k.dong@gmail.com \
--cc=robin@robinhill.me.uk \
--cc=tm@tao.ma \
/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