No syncing after crash. Is this a software raid bug?

No syncing after crash. Is this a software raid bug?

[Kasper Dupont]

I have a FC4 installation (upgraded from FC3) using kernel
version 2.6.15-1.1831_FC4. I see some symptoms in the software
raid, which I'm not quite happy about.

After an unclean shutdown caused by a crash or power failure,
it does not resync the md devices. I have tried comparing the
contents of the two mirrors for each of the md devices. And I
found that on the swap device, there were differences.

Isn't this a bug in the software raid? Shouldn't it always
resync after reboot, if there could possibly be any difference
between the contents on the two disks?

I know that as long as only swap is affected, it is not going
to cause data loss. But how can I be sure it is not going to
happen on file systems as well?

Should I report this as a bug in Fedora Core or did I miss
something?

-- 
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);
-
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

Re: No syncing after crash. Is this a software raid bug?

[Luca Berra]

On Wed, Mar 01, 2006 at 01:44:33PM +0100, Kasper Dupont wrote:
>Should I report this as a bug in Fedora Core or did I miss
>something?
>
you forgot to post evidence

L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

Re: No syncing after crash. Is this a software raid bug?

[Mike Hardy]

Why would you not be happy? resyncs in general are bad since they
indicate your data is possibly out-of-sync and the resync itself
consumes an enormous amount of resources

This is a feature of new-ish md driver code that more aggressively marks
the array as "clean" after writes

The end result is that the array will most likely be "clean" in all
circumstances even a crash, and you simply won't need to resync

That's a good thing!

-Mike

Kasper Dupont wrote:
> I have a FC4 installation (upgraded from FC3) using kernel
> version 2.6.15-1.1831_FC4. I see some symptoms in the software
> raid, which I'm not quite happy about.
> 
> After an unclean shutdown caused by a crash or power failure,
> it does not resync the md devices. I have tried comparing the
> contents of the two mirrors for each of the md devices. And I
> found that on the swap device, there were differences.
> 
> Isn't this a bug in the software raid? Shouldn't it always
> resync after reboot, if there could possibly be any difference
> between the contents on the two disks?
> 
> I know that as long as only swap is affected, it is not going
> to cause data loss. But how can I be sure it is not going to
> happen on file systems as well?
> 
> Should I report this as a bug in Fedora Core or did I miss
> something?
> 

Re: No syncing after crash. Is this a software raid bug?

[Kasper Dupont]

> Why would you not be happy? resyncs in general are bad since they
> indicate your data is possibly out-of-sync and the resync itself
> consumes an enormous amount of resources

Of course reducing the amount of resources spend on syncing is
a good thing. But it shouldn't be done at the expense of less
reliability.

> This is a feature of new-ish md driver code that more aggressively marks
> the array as "clean" after writes

A bit too aggressive it seems. How can it end up being marked
clean when the two mirrors differ?

> The end result is that the array will most likely be "clean" in all
> circumstances even a crash, and you simply won't need to resync

Shouldn't it be unclean while an update is in progress? And if
it is how come I have been completely unable to trigger a resync
even when it was reset while disks were busy writing?

Here is the program I have used to verify if the two mirrors are
in sync: http://kasperd.net/~kasperd/raidtest.c
This program find that there is a difference between the two
mirrors.

-- 
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);
-
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

Re: No syncing after crash. Is this a software raid bug?

[Mario 'BitKoenig' Holbe]

Kasper Dupont <48755289462761382922@expires.02.sep.2006.kasperd.net> wrote:
> A bit too aggressive it seems. How can it end up being marked
> clean when the two mirrors differ?

Do you have write-cache enabled on the mirrors?

Sometimes I have differences between RAID1 mirrors in 2.4, too. Even with
clean shutdown or reboot sequences. However, in my case, it turns out
that this always affects areas which are "free" on the filesystem layer.
This assumption is especially feeded by
a) the fact that the content of at least one of these differing areas is
typically zeroed and
b) that I have md5sums of all my files which don't show up any
differences when I either copy the non-zero content over the zeros or the
other way around.
Especially I have never experienced such "normal" differences on my swap
RAID1 mirrors. Until now I thought this would have to do with kernel 2.4
and block-device-specific dirty-page-flushing and missing write-barriers
and things like that which lead to blocks used for a short time only get
flushed to the one mirror but not to the other (and then, since they are
freed again, the flush to the other mirror will never happen, since the
associated pages are just not dirty anymore).
However, I thought - at least until now ;) - this would change with 2.6,
since there md has more control over the block-devices it uses.


regards
   Mario
-- 
The question of whether a computer can think is no more interesting than
the question of whether a submarine can swim.          -- E. W. Dijkstra

Re: No syncing after crash. Is this a software raid bug?

[Kasper Dupont]

> Do you have write-cache enabled on the mirrors?

How do I find out about that?

> Sometimes I have differences between RAID1 mirrors in 2.4, too.

I have not experienced this with 2.4. However the 2.4 and 2.6
machines are not exactly the same hardware. But AFAIR they both
use Promise controllers and Seagate disks.

> Even with clean shutdown or reboot sequences.

Actually I think some of the differences on the swap device have
happened on clean shutdowns.

> However, in my case, it turns out
> that this always affects areas which are "free" on the filesystem layer.

Does the raid layer have any way to know if they are free and
treat them differently?

> that I have md5sums of all my files which don't show up any
> differences when I either copy the non-zero content over the zeros or the
> other way around.

OK. Then it may very well be free areas. (Or perhaps journal)

> Especially I have never experienced such "normal" differences on my swap
> RAID1 mirrors.

So far I have only seen it happen on swap. I thought that might
be because that machine swaps a lot.

(A copy of any replies to my email address will be appreciated).

-- 
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);
-
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

Re: No syncing after crash. Is this a software raid bug?

[Mario 'BitKoenig' Holbe]

Kasper Dupont <70006427576745453539@expires.04.sep.2006.kasperd.net> wrote:
>> Do you have write-cache enabled on the mirrors?
> How do I find out about that?

for 2.4 (although I belive to remember that the reporting is broken
there) and IDE:
grep -i ^wcache /proc/ide/hd*/settings

>> that this always affects areas which are "free" on the filesystem layer.
> Does the raid layer have any way to know if they are free and

No, that's why I did put the free in quotes and did desribe how the
"free" differs from "used" :)

> So far I have only seen it happen on swap. I thought that might
> be because that machine swaps a lot.

Well, if it swaps a lot, my assumption could lead to different mirrors
in that case too - supposed my assumption is true at all :)


regards
   Mario
-- 
Tower: "Say fuelstate." Pilot: "Fuelstate."
Tower: "Say again." Pilot: "Again."
Tower: "Arghl, give me your fuel!" Pilot: "Sorry, need it by myself..."

Re: No syncing after crash. Is this a software raid bug?

[Mario 'BitKoenig' Holbe]

Mario 'BitKoenig' Holbe <Mario.Holbe@TU-Ilmenau.DE> wrote:
> grep -i ^wcache /proc/ide/hd*/settings

Ah, hdparm -I reports a Feature "Write cache" (* - enabled, no asterisk,
not enabled :))


regards
   Mario
-- 
Sex is not the answer.
Sex is the question.
Yes is the answer.

Re: No syncing after crash. Is this a software raid bug?

[Heinz Mauelshagen]

The fact that mirrors in a RAID1 set partially differ even on propper
shutdown is caused by the ability to change dirty pages *while* they
are being accessed (ie. by a mirroring driver).
This has been a fact in Linux since ever and is expected behaviour with
eg. filesystems, direct IO and memory mapped files.

Mind you that this is a block level inconsistency only, because the
fs/application will always write before it'll read the blocks in
question unless it is not well-behanved.

An example for a filesystem causing this is a file write followed
by a file truncation.

Regards,
Heinz    -- The LVM Guy --

On Thu, Mar 02, 2006 at 02:48:25PM +0100, Mario 'BitKoenig' Holbe wrote:
> Kasper Dupont <48755289462761382922@expires.02.sep.2006.kasperd.net> wrote:
> > A bit too aggressive it seems. How can it end up being marked
> > clean when the two mirrors differ?
> 
> Do you have write-cache enabled on the mirrors?
> 
> Sometimes I have differences between RAID1 mirrors in 2.4, too. Even with
> clean shutdown or reboot sequences. However, in my case, it turns out
> that this always affects areas which are "free" on the filesystem layer.
> This assumption is especially feeded by
> a) the fact that the content of at least one of these differing areas is
> typically zeroed and
> b) that I have md5sums of all my files which don't show up any
> differences when I either copy the non-zero content over the zeros or the
> other way around.
> Especially I have never experienced such "normal" differences on my swap
> RAID1 mirrors. Until now I thought this would have to do with kernel 2.4
> and block-device-specific dirty-page-flushing and missing write-barriers
> and things like that which lead to blocks used for a short time only get
> flushed to the one mirror but not to the other (and then, since they are
> freed again, the flush to the other mirror will never happen, since the
> associated pages are just not dirty anymore).
> However, I thought - at least until now ;) - this would change with 2.6,
> since there md has more control over the block-devices it uses.
> 
> 
> regards
>    Mario
> -- 
> The question of whether a computer can think is no more interesting than
> the question of whether a submarine can swim.          -- E. W. Dijkstra
> 
> -
> 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

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Red Hat GmbH
Consulting Development Engineer                   Am Sonnenhang 11
Cluster and Storage Development                   56242 Marienrachdorf
                                                  Germany
Mauelshagen@RedHat.com                            +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: No syncing after crash. Is this a software raid bug?

[Mario 'BitKoenig' Holbe]

Heinz Mauelshagen <mauelshagen@redhat.com> wrote:
> The fact that mirrors in a RAID1 set partially differ even on propper
> shutdown is caused by the ability to change dirty pages *while* they
> are being accessed (ie. by a mirroring driver).

That's quite the scenario what I thought about, but more clear now,
thanks.
But when a dirty page is modified while it's being accessed, it stays
dirty and gets cleaned (i.e. written to disk) later again, right? This
would imply that the mirrors should always be equal after a clean
shutdown, which in fact is not true.

> Mind you that this is a block level inconsistency only, because the
...
> An example for a filesystem causing this is a file write followed
> by a file truncation.

Yes, this is also quite similar to the scenario what I thought about -
especially it suggests that this case happens only on "free" space.

However, Kaspers case is a bit different, since it involves swap space,
which leads to the suspicion that there are cases where mirror
differences could occur also on "non-free" space (although there is
of course also something like "free" space on swap and one had to
analyze if it's such space that is affected, which most likely isn't
the simplest thing at all :)). While swap is probably quite robust
against such a scenario, since it's not valid after a reboot anymore,
I could imagine other cases (i.e. database raw devices) where subsequent
reads lead to different data due to the different mirrors, isn't it?
And couldn't this happen even on swap without reboot inbetween when a
page really needs to be read from disk?


regards
   Mario
-- 
File names are infinite in length where infinity is set to 255 characters.
                                -- Peter Collinson, "The Unix File System"

Re: No syncing after crash. Is this a software raid bug?

[Kasper Dupont]

> grep -i ^wcache /proc/ide/hd*/settings

On the 2.6 system where I see the differences between mirrors
I get this result from above command:

/proc/ide/hde/settings:wcache                  1               0               1               rw
/proc/ide/hdg/settings:wcache                  1               0               1               rw

On a 2.4 system where I see no differences between mirrors I
get this result from above command:

/proc/ide/hda/settings:wcache                  0               0               1               rw
/proc/ide/hdc/settings:wcache                  0               0               1               rw
/proc/ide/hde/settings:wcache                  0               0               1               rw
/proc/ide/hdg/settings:wcache                  0               0               1               rw

So how should I interpret this?

(A copy of any replies to my email address will be appreciated).

-- 
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);
-
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

Re: No syncing after crash. Is this a software raid bug?

[Mario 'BitKoenig' Holbe]

Kasper Dupont <87385155133026632046@expires.04.sep.2006.kasperd.net> wrote:
> On the 2.6 system where I see the differences between mirrors
> /proc/ide/hde/settings:wcache                  1

write cache enabled.
Btw... don't disable it on a production system without previously
thinking about it :) Disabling write cache leads to massive performance
decrease on heavy simultaneous I/O... On a system with (IMHO not heavy
but significant) simultaneous I/O I got 35MB/s write speed on dd with
write cache enabled and it shrunk down to 9MB/s with write cache
disabled - while load grew up from ~0 to ~8.

> On a 2.4 system where I see no differences between mirrors I
> /proc/ide/hde/settings:wcache                  0               0               1               rw
> So how should I interpret this?

As I said - on 2.4 write cache reporting through /proc is broken: it
always reports disabled write cache, while it is not necessarily
disabled. Use hdparm -I instead (big I, not small i).


regards
   Mario
-- 
"Why are we hiding from the police, daddy?"      | J. E. Guenther
"Because we use SuSE son, they use SYSVR4."      | de.alt.sysadmin.recovery

Re: No syncing after crash. Is this a software raid bug?

[Heinz Mauelshagen]

On Fri, Mar 03, 2006 at 03:30:29PM +0100, Mario 'BitKoenig' Holbe wrote:
> Heinz Mauelshagen <mauelshagen@redhat.com> wrote:
> > The fact that mirrors in a RAID1 set partially differ even on propper
> > shutdown is caused by the ability to change dirty pages *while* they
> > are being accessed (ie. by a mirroring driver).
> 
> That's quite the scenario what I thought about, but more clear now,
> thanks.
> But when a dirty page is modified while it's being accessed, it stays
> dirty and gets cleaned (i.e. written to disk) later again, right?

Well, cleaing a dirty page isn't a 1:1 action with respect to writing.
A mirroring driver (eg. the MD raid1 personality), will access the dirty
page multiple times to store the data on multiple mirrors before the dirty
flag will be cleared during endio processing.

> This
> would imply that the mirrors should always be equal after a clean
> shutdown, which in fact is not true.

Think roughly:

o page gets dirtied
o page gets handed to mirroring driver
o mirroring driver initiates writes to all mirrors
o write gets through to first mirror
o page content gets changed
o second write gets through to other mirror

> 
> > Mind you that this is a block level inconsistency only, because the
> ...
> > An example for a filesystem causing this is a file write followed
> > by a file truncation.
> 
> Yes, this is also quite similar to the scenario what I thought about -
> especially it suggests that this case happens only on "free" space.
> 
> However, Kaspers case is a bit different, since it involves swap space,
> which leads to the suspicion that there are cases where mirror
> differences could occur also on "non-free" space (although there is
> of course also something like "free" space on swap and one had to
> analyze if it's such space that is affected, which most likely isn't
> the simplest thing at all :)). While swap is probably quite robust
> against such a scenario, since it's not valid after a reboot anymore,

Yes. This is a don't care.

> I could imagine other cases (i.e. database raw devices) where subsequent
> reads lead to different data due to the different mirrors, isn't it?

This is what I meant by well-behaved applications.
The DBMS will write to such (eventually) inconsistent blocks
*before* it'll read them back in hence removing the block-level inconsistency.

> And couldn't this happen even on swap without reboot inbetween when a
> page really needs to be read from disk?

It shouldn't, because page-ins will follow page-outs first.
Meanwhile the transient page table(s) will contain the disk address(es)
of the respective page(s).

Heinz

> 
> 
> regards
>    Mario
> -- 
> File names are infinite in length where infinity is set to 255 characters.
>                                 -- Peter Collinson, "The Unix File System"
> 
> -
> 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

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Red Hat GmbH
Consulting Development Engineer                   Am Sonnenhang 11
Cluster and Storage Development                   56242 Marienrachdorf
                                                  Germany
Mauelshagen@RedHat.com                            +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: No syncing after crash. Is this a software raid bug?

[Mario 'BitKoenig' Holbe]

Heinz Mauelshagen <mauelshagen@redhat.com> wrote:
> On Fri, Mar 03, 2006 at 03:30:29PM +0100, Mario 'BitKoenig' Holbe wrote:
>> But when a dirty page is modified while it's being accessed, it stays
>> dirty and gets cleaned (i.e. written to disk) later again, right?
> A mirroring driver (eg. the MD raid1 personality), will access the dirty
> page multiple times to store the data on multiple mirrors before the dirty
> flag will be cleared during endio processing.

So the dirty flag *is* cleared even if the page was modified while the
mirroring driver did access it?

> o write gets through to first mirror
> o page content gets changed
> o second write gets through to other mirror
...
> This is what I meant by well-behaved applications.
> The DBMS will write to such (eventually) inconsistent blocks
> *before* it'll read them back in hence removing the block-level inconsistency.
>> And couldn't this happen even on swap without reboot inbetween when a
>> page really needs to be read from disk?
> It shouldn't, because page-ins will follow page-outs first.
> Meanwhile the transient page table(s) will contain the disk address(es)
> of the respective page(s).

But given the rough scenario above there *are* page-outs first.
Wouldn't it be possible (in both cases: the DBMS as well as the swap
scenario), that the now cleaned page is read in later from the first
mirror and thus contains the old content which was written before it
got changed, written to the other mirror and got cleared?


regards
   Mario
-- 
<jv> Oh well, config
<jv> one actually wonders what force in the universe is holding it
<jv> and makes it working
<Beeth> chances and accidents :)

Re: No syncing after crash. Is this a software raid bug?

[Heinz Mauelshagen]

On Sat, Mar 04, 2006 at 12:01:50AM +0100, Mario 'BitKoenig' Holbe wrote:
> Heinz Mauelshagen <mauelshagen@redhat.com> wrote:
> > On Fri, Mar 03, 2006 at 03:30:29PM +0100, Mario 'BitKoenig' Holbe wrote:
> >> But when a dirty page is modified while it's being accessed, it stays
> >> dirty and gets cleaned (i.e. written to disk) later again, right?
> > A mirroring driver (eg. the MD raid1 personality), will access the dirty
> > page multiple times to store the data on multiple mirrors before the dirty
> > flag will be cleared during endio processing.
> 
> So the dirty flag *is* cleared even if the page was modified while the
> mirroring driver did access it?

Yes, *after* it accessed it multiple times in order to update the
mirrors in the set. The mirroring driver doesn't track such changes.
If it relies on static page content during updates of its mirrors, it
need to take a private copy of the page(s).

> 
> > o write gets through to first mirror
> > o page content gets changed
> > o second write gets through to other mirror
> ...
> > This is what I meant by well-behaved applications.
> > The DBMS will write to such (eventually) inconsistent blocks
> > *before* it'll read them back in hence removing the block-level inconsistency.
> >> And couldn't this happen even on swap without reboot inbetween when a
> >> page really needs to be read from disk?
> > It shouldn't, because page-ins will follow page-outs first.
> > Meanwhile the transient page table(s) will contain the disk address(es)
> > of the respective page(s).
> 
> But given the rough scenario above there *are* page-outs first.
> Wouldn't it be possible (in both cases: the DBMS as well as the swap
> scenario), that the now cleaned page is read in later from the first
> mirror and thus contains the old content which was written before it
> got changed, written to the other mirror and got cleared?

No, a write before another read will happen unless you
found an unknown bogus case ;)

Heinz

> 
> 
> regards
>    Mario
> -- 
> <jv> Oh well, config
> <jv> one actually wonders what force in the universe is holding it
> <jv> and makes it working
> <Beeth> chances and accidents :)
> 
> -
> 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

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Red Hat GmbH
Consulting Development Engineer                   Am Sonnenhang 11
Cluster and Storage Development                   56242 Marienrachdorf
                                                  Germany
Mauelshagen@RedHat.com                            +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: No syncing after crash. Is this a software raid bug?

[Mario 'BitKoenig' Holbe]

Heinz Mauelshagen <mauelshagen@redhat.com> wrote:
>> But given the rough scenario above there *are* page-outs first.
> No, a write before another read will happen unless you
> found an unknown bogus case ;)

Well, taking your rough scenario again, assigning it to a swap case
(although it should be the same with a mmap()ing DBMS)...

o page gets dirtied
...probably lots of activity...
o page gets pro-actively synched to swap - handed to mirroring driver
o mirroring driver initiates writes to all mirrors
o write gets through to first mirror
o page content gets changed (page is still dirty)
o second write gets through to other mirror, page gets cleaned
...probably lots of activity...
o low on physical memory, clean page gets re-mapped somewhere else
...probably lots of activity...
o access to the virtual memory page that is now not mapped anymore
  (the one that was previously mapped to our now re-mapped page)
o new mapping is created
o page content is read from swap - handed to mirroring driver
o mirroring driver initiates read to the first mirror
o page contains content before the last change

Okay, the scenario is probably bogus in the way that the access pattern
is quite special:
1. you need an access pattern where a page is accessed very seldom
   (so it constantly runs out of the working set)
2. the race condition with the paging strategy needs to occur while one
   of these seldom accesses (especially while a page modify)


regards
   Mario
-- 
Ho ho ho! I am Santa Claus of Borg. Nice assimilation all together!

Re: No syncing after crash. Is this a software raid bug?

[Kasper Dupont]

> If it relies on static page content during updates of its mirrors, it
> need to take a private copy of the page(s).

And by that you mean that raid5 and raid6 must copy the page
contents before writing it to disk?

-- 
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);
-
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

Re: No syncing after crash. Is this a software raid bug?

[Mario 'BitKoenig' Holbe]

Kasper Dupont <10616252720827252562@expires.05.sep.2006.kasperd.net> wrote:
> And by that you mean that raid5 and raid6 must copy the page
> contents before writing it to disk?

They must not :) But if they don't, they risk inconsistent parity
information to be calculated.
However, since "inconsistent parity information in raid[456] is equal
to "different mirrors" in raid1, there is no real difference. So I
doubt they will copy :)


regards
   Mario
-- 
<jv> Oh well, config
<jv> one actually wonders what force in the universe is holding it
<jv> and makes it working
<Beeth> chances and accidents :)

Re: No syncing after crash. Is this a software raid bug?

[Kasper Dupont]

> However, since "inconsistent parity information in raid[456] is equal
> to "different mirrors" in raid1, there is no real difference.

There is a major difference. Inconsistent parity information can
eventually lead to corruption in another sector in the stripe.
Assume there are two data disks and one parity disk, and two
different versions of sector A are used. Then after a write you
would end up with:

A  B  A'+B

on the three disks. This is a problem even if you are never
going to need the data from A again. If the disk holding B dies
it will be reconstructed as (A)+(A'+B), which does not give B
as it should. So after reconstruction sector B is corrupted.

-- 
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);
-
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

Re: No syncing after crash. Is this a software raid bug?

[Heinz Mauelshagen]

On Sat, Mar 04, 2006 at 02:16:11PM +0100, Kasper Dupont wrote:
> > If it relies on static page content during updates of its mirrors, it
> > need to take a private copy of the page(s).
> 
> And by that you mean that raid5 and raid6 must copy the page
> contents before writing it to disk?

Yes.
They need to do it anayway in order to calculate parity blocks.

> 
> -- 
> Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
> #define _(_)"d.%.4s%."_"2s" /* This is my new email address */
> char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);
> -
> 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

Regards,
Heinz    -- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Red Hat GmbH
Consulting Development Engineer                   Am Sonnenhang 11
Cluster and Storage Development                   56242 Marienrachdorf
                                                  Germany
Mauelshagen@RedHat.com                            +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
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

Re: No syncing after crash. Is this a software raid bug?

[Kasper Dupont]

On 07/03/06 11.47, Heinz Mauelshagen wrote:
> On Sat, Mar 04, 2006 at 02:16:11PM +0100, Kasper Dupont wrote:
> > > If it relies on static page content during updates of its mirrors, it
> > > need to take a private copy of the page(s).
> > 
> > And by that you mean that raid5 and raid6 must copy the page
> > contents before writing it to disk?
> 
> Yes.
> They need to do it anayway in order to calculate parity blocks.

OK, I'll do some testing with raid5 then. I want to know if it
behaves differently from raid1 in this respect.

-- 
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);
-
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

Re: No syncing after crash. Is this a software raid bug?

[Heinz Mauelshagen]

On Tue, Mar 07, 2006 at 12:18:35PM +0100, Kasper Dupont wrote:
> On 07/03/06 11.47, Heinz Mauelshagen wrote:
> > On Sat, Mar 04, 2006 at 02:16:11PM +0100, Kasper Dupont wrote:
> > > > If it relies on static page content during updates of its mirrors, it
> > > > need to take a private copy of the page(s).
> > > 
> > > And by that you mean that raid5 and raid6 must copy the page
> > > contents before writing it to disk?
> > 
> > Yes.
> > They need to do it anayway in order to calculate parity blocks.
> 
> OK, I'll do some testing with raid5 then. I want to know if it
> behaves differently from raid1 in this respect.

Yes, it definitely should.

Heinz

> 
> -- 
> Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
> #define _(_)"d.%.4s%."_"2s" /* This is my new email address */
> char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Red Hat GmbH
Consulting Development Engineer                   Am Sonnenhang 11
Cluster and Storage Development                   56242 Marienrachdorf
                                                  Germany
Mauelshagen@RedHat.com                            +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
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

Re: No syncing after crash. Is this a software raid bug?

[Heinz Mauelshagen]

On Tue, Mar 07, 2006 at 12:18:35PM +0100, Kasper Dupont wrote:
> On 07/03/06 11.47, Heinz Mauelshagen wrote:
> > On Sat, Mar 04, 2006 at 02:16:11PM +0100, Kasper Dupont wrote:
> > > > If it relies on static page content during updates of its mirrors, it
> > > > need to take a private copy of the page(s).
> > > 
> > > And by that you mean that raid5 and raid6 must copy the page
> > > contents before writing it to disk?
> > 
> > Yes.
> > They need to do it anayway in order to calculate parity blocks.
> 
> OK, I'll do some testing with raid5 then. I want to know if it
> behaves differently from raid1 in this respect.

Have you got results yet ?

Heinz

> 
> -- 
> Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
> #define _(_)"d.%.4s%."_"2s" /* This is my new email address */
> char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Red Hat GmbH
Consulting Development Engineer                   Am Sonnenhang 11
Cluster and Storage Development                   56242 Marienrachdorf
                                                  Germany
Mauelshagen@RedHat.com                            +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
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

Re: No syncing after crash. Is this a software raid bug?

[Kasper Dupont]

On 10/03/06 08.43, Heinz Mauelshagen wrote:
> On Tue, Mar 07, 2006 at 12:18:35PM +0100, Kasper Dupont wrote:
> > 
> > OK, I'll do some testing with raid5 then. I want to know if it
> > behaves differently from raid1 in this respect.
> 
> Have you got results yet ?

No, not yet. I'll tell you as soon as I have some. I rarely have
physical access to the machine, I just take care of the
administration. But I have now switched the swap on that machine
from raid1 to raid5, so I expect to be able to tell you something
early next week.

-- 
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);
-
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

Re: No syncing after crash. Is this a software raid bug?

[Kasper Dupont]

On 10/03/06 08.49, Kasper Dupont wrote:
> On 10/03/06 08.43, Heinz Mauelshagen wrote:
> > On Tue, Mar 07, 2006 at 12:18:35PM +0100, Kasper Dupont wrote:
> > > 
> > > OK, I'll do some testing with raid5 then. I want to know if it
> > > behaves differently from raid1 in this respect.
> > 
> > Have you got results yet ?
> 
> No, not yet. I'll tell you as soon as I have some.

OK now I have some results. I could not reproduce the symptoms
with raid5. As long as this only shows up with raid1, there is
not much reason to worry.

-- 
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);
-
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

Re: No syncing after crash. Is this a software raid bug?

[Heinz Mauelshagen]

On Thu, Mar 16, 2006 at 08:24:52AM +0100, Kasper Dupont wrote:
> On 10/03/06 08.49, Kasper Dupont wrote:
> > On 10/03/06 08.43, Heinz Mauelshagen wrote:
> > > On Tue, Mar 07, 2006 at 12:18:35PM +0100, Kasper Dupont wrote:
> > > > 
> > > > OK, I'll do some testing with raid5 then. I want to know if it
> > > > behaves differently from raid1 in this respect.
> > > 
> > > Have you got results yet ?
> > 
> > No, not yet. I'll tell you as soon as I have some.
> 
> OK now I have some results. I could not reproduce the symptoms
> with raid5.

Good and as expected.

> As long as this only shows up with raid1, there is
> not much reason to worry.

Alright.

Regards,
Heinz

> 
> -- 
> Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
> #define _(_)"d.%.4s%."_"2s" /* This is my new email address */
> char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Red Hat GmbH
Consulting Development Engineer                   Am Sonnenhang 11
Storage Development                               56242 Marienrachdorf
                                                  Germany
Mauelshagen@RedHat.com                            PHONE +49  171 7803392
                                                  FAX   +49 2626 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
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