linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "JaniD++" <djani22@dynamicweb.hu>
To: Neil Brown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: RAID5 resync question
Date: Wed, 7 Dec 2005 02:32:49 +0100	[thread overview]
Message-ID: <020201c5face$23700cc0$0400a8c0@dcccs> (raw)
In-Reply-To: 17302.9182.322057.18613@cse.unsw.edu.au

> >
> > One time while my array is really rebuild one disk (paralel normal
> > workload), i see, the new drive in the array *only* writes.
> > i means with "better handling of half-synced array" is this:
> > If read request comes to the ?% synced array, and if the read is on the
> > synced half, only need to read from *new* device, instead reading all
other
> > to calculate data from parity.
> >
> > On a working system this can be a little speed up the rebuild process,
and
> > some offload the system.
> > Or i'm on a wrong clue? :-)
>
> Yes, it would probably be possible to get it to read from the
> recovering drive once that section had been recovered.  I'll put it on
> my todo list.

If i can add some idea to the world's greatest raid software, it is my
pleasure! :-)

But, Neil!
It is still something what i cannot understand.

(Preliminary, i never have read the raid5 code.
However i cannot programming in C or C++, only a little can read.)

I cannot cleanly understand what u sad about the parity-updating!

If the array is clean, the parity spaces (blocks) only need to write. (or
not?)
Why use the raid code read-modify-write?
I think it is unnecessary to read these blocks!
The parity block recalculate in memory is more faster than
read-modify-write.

Why the parity space is continous area? (if it is...)
I think it is only need to be block-based, from a lot of independent blocks.
This can be speed up the resync, easy to using always checkpoints, and some
more...

And if the parity data is damaged (like system crash or sg.), and it is
impossible to detect, the next write to the block will turn to correct again
the parity.

Cheers,
Janos



>
> NeilBrown


  reply	other threads:[~2005-12-07  1:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-06  0:18 RAID5 resync question JaniD++
2005-12-06  0:32 ` Neil Brown
2005-12-06  0:45   ` JaniD++
2005-12-06  1:05     ` Neil Brown
2005-12-06 10:56       ` JaniD++
2005-12-06 23:50         ` Neil Brown
2005-12-07  1:32           ` JaniD++ [this message]
2005-12-08 23:00       ` RAID5 resync question BUGREPORT! JaniD++
2005-12-08 23:43         ` Neil Brown
2005-12-09  4:03           ` JaniD++
2005-12-09  4:49             ` Neil Brown
2005-11-17  1:09               ` JaniD++
2005-12-19  0:57                 ` Neil Brown
2005-12-19 10:34                   ` JaniD++
2005-12-22  4:46                     ` Neil Brown
2005-11-23  9:38                       ` JaniD++

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='020201c5face$23700cc0$0400a8c0@dcccs' \
    --to=djani22@dynamicweb.hu \
    --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).