Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: SandeepKsinha <sandeepksinha@gmail.com>
Cc: Redeeman <redeeman@metanurb.dk>,
	Goswin von Brederlow <goswin-v-b@web.de>,
	John Robinson <john.robinson@anonymous.org.uk>,
	Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: RAID5 reconstruction ?
Date: Sun, 31 May 2009 13:54:29 +0200	[thread overview]
Message-ID: <87ljod7aiy.fsf@frosties.localdomain> (raw)
In-Reply-To: <37d33d830905310102m451f26aaw8e233227cda491c@mail.gmail.com> (sandeepksinha@gmail.com's message of "Sun, 31 May 2009 13:32:03 +0530")

SandeepKsinha <sandeepksinha@gmail.com> writes:

> On Sun, May 31, 2009 at 1:07 AM, Redeeman <redeeman@metanurb.dk> wrote:
>> On Sat, 2009-05-30 at 20:55 +0200, Goswin von Brederlow wrote:
>>> And just when I hit send I thought of something else.
>>>
>>> Instead of the initial sync when creating a raid the bitmap could just
>>> mark all blocks as unused. Much faster raid creation.
>>
>
>
> This really sounds like a good option. This would have a slight hit
> for writes which I believe will compensate for later re-constructions,
> replacing a disk, mirror resysnc and many more operation.

What hit? Currently with bitmap support a write will set the block to
"unclean", write the data, write the parity and set the block to
"clean". Setting the "used" bit along the way should not cost much.

Only difference I see is that the bitmap would have to have finer
granularity so one "used" bit covers one filesystem block (4k usualy).
Otherwise you could only "use" blocks but not "unuse" them again when
the filesystem frees them in 4k chunks.

> Neil any comments on this?
>
> I mean, how difficult would it be to maintain such a bitmap. This can
> though of making something optional as this will incur space.
>
>
>> A filesystem-coexist mode could also do this, by simply refusing
>> operation until such a time that a filesystem is detected, or i suppose
>> in worst case, mounted...
>
>
>>
>>>
>>> MfG
>>>         Goswin

MfG
        Goswin
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2009-05-31 11:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-30  5:44 RAID5 reconstruction ? SandeepKsinha
2009-05-30 12:52 ` Sujit Karataparambil
2009-05-30 13:28   ` SandeepKsinha
2009-05-30 13:31     ` Sujit Karataparambil
2009-06-09  4:13   ` Nifty Fedora Mitch
2009-05-30 13:35 ` John Robinson
2009-05-30 14:06   ` Maxime Boissonneault
2009-05-30 15:46     ` John Robinson
2009-05-30 16:16       ` Maxime Boissonneault
2009-05-30 16:30         ` John Robinson
2009-05-30 16:08   ` Redeeman
2009-05-30 18:39     ` Bill Davidsen
2009-05-30 18:54     ` Goswin von Brederlow
2009-05-31  8:10       ` SandeepKsinha
2009-05-30 18:55     ` Goswin von Brederlow
2009-05-30 19:37       ` Redeeman
2009-05-31  8:02         ` SandeepKsinha
2009-05-31 11:54           ` Goswin von Brederlow [this message]
2009-05-31 12:11             ` John Robinson
2009-05-31 12:14             ` NeilBrown
2009-06-03  1:54               ` Greg Freemyer
2009-06-02 18:42       ` 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=87ljod7aiy.fsf@frosties.localdomain \
    --to=goswin-v-b@web.de \
    --cc=john.robinson@anonymous.org.uk \
    --cc=linux-raid@vger.kernel.org \
    --cc=redeeman@metanurb.dk \
    --cc=sandeepksinha@gmail.com \
    /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