Hi,
What exactly is the command to recover a raid array after system crash? I
created a raid5 array with 3 disks. After system crash, one disk is out
of sync, so I tried the command
mdadm --assemble --run --force --update=resync /dev/md2 /dev/sbd3 /dev/sbd4
/dev/sbd5
However, I still saw that
Michael Tokarev <[EMAIL PROTECTED]> wrote:
> The point a) is moot, because this whole structure is used in raid1.c ONLY.
> (I don't know why it is placed into raid1.h header file instead of into
> raid1.c directly, but that's a different topic).
Hmm. I'm a little surprised. I would be worried that
Peter T. Breuer wrote:
Michael Tokarev <[EMAIL PROTECTED]> wrote:
[]
But your approach is fine - it's just that (a) I don't like to mess
with the struct sizes, as that makes modules binary incompatible,
instead of just having extra functionalities, and (b) I really think
it's not going to be easily
Michael Tokarev <[EMAIL PROTECTED]> wrote:
> > Uh OK. As I recall one only needs to count, one doesn't need a bitwise
> > map of what one has dealt with.
>
> Well. I see read_balance() is now used to resubmit reads. There's
> a reason to use it instead of choosing "next" disk, I think.
I can't
Lars Marowsky-Bree wrote:
On 2005-03-19T12:44:14, Guy <[EMAIL PROTECTED]> wrote:
In the case of a split brain, I think one must be 100% voided, and a full
re-sync must be done.
Exactly. And that's where the bitmaps come into play; you can look at
what is modified on each side, merge those s
Peter T. Breuer wrote:
Michael Tokarev <[EMAIL PROTECTED]> wrote:
[-- text/plain, encoding 7bit, charset: KOI8-R, 74 lines --]
Uh-oh. Setting proper charset this time. What a nonsense:
7bit but koi8... ;)
[]
Uh OK. As I recall one only needs to count, one doesn't need a bitwise
map of what one ha
Guy <[EMAIL PROTECTED]> wrote:
> I agree, but I don't think a block device can to a re-sync without
> corrupting both. How do you merge a superset at the block level? AND the 2
Don't worry - it's just a one-way copy done efficiently (i.e., leaving
out all the blocks known to be unmodified both s
Oh! I never read it like you just said. I have been reading it like copy
in both directions based on both bitmaps! What you said below, seems
reasonable.
Guy
-Original Message-
From: Lars Marowsky-Bree [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 19, 2005 12:54 PM
To: Guy; 'Peter T
On 2005-03-19T12:44:14, Guy <[EMAIL PROTECTED]> wrote:
> In the case of a split brain, I think one must be 100% voided, and a full
> re-sync must be done.
Exactly. And that's where the bitmaps come into play; you can look at
what is modified on each side, merge those sets, and copy all affected
b
On 2005-03-19T18:19:44, "Peter T. Breuer" <[EMAIL PROTECTED]> wrote:
> > That part is really simple in theory.
>
> Knowing which blocks are/may be different does not help them decide who is
> _right_.
>
> Lars, I am trying to move you "upwards" from the detail of the
> algorithms to a level at
You said:
"Wrong model. They know that at one point in time they've been in sync,
and that they have since diverged, and so they can figure out where
those differences occur."
I agree, but I don't think a block device can to a re-sync without
corrupting both. How do you merge a superset at the bl
Lars Marowsky-Bree <[EMAIL PROTECTED]> wrote:
> On 2005-03-19T16:06:29, "Peter T. Breuer" <[EMAIL PROTECTED]> wrote:
>
> I'm cutting out those parts of the discussion which are irrelevant (or
> which I don't consider worth pursuing; maybe you'll find someone else
> to explain with more patience).
Michael Tokarev <[EMAIL PROTECTED]> wrote:
> [-- text/plain, encoding 7bit, charset: KOI8-R, 74 lines --]
>
> Peter T. Breuer wrote:
> []
> > The patch was originally developed for 2.4, then ported to 2.6.3, and
> > then to 2.6.8.1. Neil has recently been doing stuff, so I don't
> > think it appli
On 2005-03-19T16:06:29, "Peter T. Breuer" <[EMAIL PROTECTED]> wrote:
I'm cutting out those parts of the discussion which are irrelevant (or
which I don't consider worth pursuing; maybe you'll find someone else
to explain with more patience).
> > > Hmm. I don't believe it can detect it reliably. I
Peter T. Breuer wrote:
[]
The patch was originally developed for 2.4, then ported to 2.6.3, and
then to 2.6.8.1. Neil has recently been doing stuff, so I don't
think it applies cleanly to 2.6.10, but somebody WAS porting it for me
until they found that 2.6.10 didn't support their hardware ... and I
Mario Holbe <[EMAIL PROTECTED]> wrote:
> Peter T. Breuer <[EMAIL PROTECTED]> wrote:
> > Lars Marowsky-Bree <[EMAIL PROTECTED]> wrote:
> >> Split-brain is a well studied subject, and while many prevention
> >> strategies exist, errors occur even in these algorithms;
> > Show me how :-(. The algorit
Peter T. Breuer <[EMAIL PROTECTED]> wrote:
> Lars Marowsky-Bree <[EMAIL PROTECTED]> wrote:
>> Split-brain is a well studied subject, and while many prevention
>> strategies exist, errors occur even in these algorithms;
> Show me how :-(. The algorithm is perfectly simple: block, flush one,
> stop
Lars Marowsky-Bree <[EMAIL PROTECTED]> wrote:
> On 2005-03-19T14:27:45, "Peter T. Breuer" <[EMAIL PROTECTED]> wrote:
>
> > > Which one of the datasets you choose you could either arbitate via some
> > > automatic mechanisms (drbd-0.8 has a couple) or let a human decide.
> > But how on earth can yo
Hello,
here goes multipath-tools-0.4.3
This is a bugfix and features release.
Things noticable from users' perspective :
* dropped klibc from the package : now an external dependency.
Those interested in building the tools with klcc will want to
download klibc from http://
On 2005-03-19T14:27:45, "Peter T. Breuer" <[EMAIL PROTECTED]> wrote:
> > Which one of the datasets you choose you could either arbitate via some
> > automatic mechanisms (drbd-0.8 has a couple) or let a human decide.
> But how on earth can you get into this situation? It still is not clear
> to me
Lars Marowsky-Bree <[EMAIL PROTECTED]> wrote:
> On 2005-03-19T12:43:41, "Peter T. Breuer" <[EMAIL PROTECTED]> wrote:
>
> > Well, there is the "right data" from our point of view, and it is what
> > should by on (one/both?) device by now. One doesn't get to recover that
> > "right data" by copying
On 2005-03-19T12:43:41, "Peter T. Breuer" <[EMAIL PROTECTED]> wrote:
> Well, there is the "right data" from our point of view, and it is what
> should by on (one/both?) device by now. One doesn't get to recover that
> "right data" by copying one disk over another, however efficiently one
> does i
Michael Tokarev <[EMAIL PROTECTED]> wrote:
> Ok, you intrigued me enouth already.. what's the FR1 patch? I want
> to give it a try... ;) Especially I'm interested in the "Robust Read"
> thing...
That was published on this list a few weeks ago (probably needs updating,
but I am sure you can help
Peter T. Breuer wrote:
Michael Tokarev <[EMAIL PROTECTED]> wrote:
[]
o For md, all drives are equal, that is, for example, raid1
code will balance reads among all the available drives a-la
Not necessarily so. At least part of the FR1 patch is dedicated to
timing the latencies of the disks, and cho
Michael Tokarev <[EMAIL PROTECTED]> wrote:
> Luca Berra wrote:
> > On Fri, Mar 18, 2005 at 02:42:55PM +0100, Lars Marowsky-Bree wrote:
> >
> >> The problem is for multi-nodes, both sides have their own bitmap. When a
> >> split scenario occurs, and both sides begin modifying the data, that
> >> bi
Paul Clements <[EMAIL PROTECTED]> wrote:
> Peter T. Breuer wrote:
> > I don't see that this solves anything. If you had both sides going at
> > once, receiving different writes, then you are sc&**ed, and no
> > resolution of bitmaps will help you, since both sides have received
> > different (legit
On 2005-03-19T00:46:51, Michael Tokarev <[EMAIL PROTECTED]> wrote:
> o DRBD allows local drive to be a bit ahead compared to remote one
> (configurable), while md will wait for all drives to complete a write.
The async writes have been added to md recently my Paul too.
> There's a case which is
Mario Holbe <[EMAIL PROTECTED]> wrote:
> Peter T. Breuer <[EMAIL PROTECTED]> wrote:
> > Yes, you can "sync" them by writing any one of the two mirrors to the
> > other one, and need do so only on the union of the mapped data areas,
>
> As far as I understand the issue, this is exactly what should
28 matches
Mail list logo
