Re: SUSE 9.2: SoftRAID infinte sync!

From: Peter T. Breuer (
Date: 11/21/04

Date: Sun, 21 Nov 2004 15:25:33 +0100

Michael Heiming <> wrote:
> In comp.os.linux.setup Peter T. Breuer <>:
> > Harald Schneider <> wrote:
> [..]
> >> again: after 100% it restarted to sync again. This is pretty weird. Using
> > No it is not "weird", it means you have a faulty implementation of
> > softraid. Get another one. Use a different kernel or softraid driver.

Hi Michael!

> IIRC, mirroring the complete system via sw raid doesn't work on
> suse, at least on sles 8 it doesn't. Setup sw raid on an already
> installed (unmirrored) system, which worked fine, but it couldn't
> reboot. For the fun of it, tried installing from scratch, but
> alas the installer said it couldn't setup the complete system
> with sw raid. Strange, this setup works on redhat quite nice, the
> raid can be setup via kickstart auto-magically.

It is purely a kernel thing. If they have the kernel module, and their
patches have not messed it up (which is possible!), then it will work.
There are no ifs and buts - nothing else is involved apart from the
kernel, which you can change to your taste :).

> It can still boot with a single disk in case of failure.


> > Absolutely. And not /var. And not swap. And not journals. And try and
> > avoid journalled filesystems over raid as some conditions for
> > journalling are not met.
> As already written works fine with redhat, perhaps some obscure
> rh patches?

No - it does not work fine because it can't. Journalled file systems
cannot work (in the sense of doing what they are supposed to :) unless
the order of write requests hitting the disk matches the order of write
requests emitted. And reads must hit disk after the write request that
preceded them! You can understand why.

Under ordinary conditions the ide driver just sends and receives in the
order that it gets the requests. But even the ide driver has an
internal queue - internally it could reorder writes, and that would
invalidate the consistency on disk of the file system, as it is
purported to be "guaranteed" by the Jfs. This happens more often the
more parallelism and asynchronicity there is in the system, and the
more heavily it is used. Put two disks in there on two different
channels and a large internal queue on each channel and all bets are
off as to the ordering. And THEN there is the problem that nothing that
passes through the raid driver gets any guarantee of order preservatoon
at all, even if there is only one disk in the raid, since the driver
does not attempt to check or maintain ordering. It's all down to luck.

The slower the media is and the faster the cpu (i..e the greater the
load), the more likley you are to see effects.

> Anyway, for real I/O on an already loaded system, I'd suggest hw
> raid, which has some advantages. A (hot-plug) disk can be
> replaced without any knowledge, simply plug&play, the controller

As in softraid - provided you can hotplug on the bus in question at all.
If it is scsi, umm, probably you can. If it is IDE, pray.

> will do anything to rebuild the array. You can later check with
> whatever tool the vendor provides for linux, if anything is fine.
> Just make sure there's a tool running under linux, before you get
> a hw raid controller.
> The cheaper ones aren't known to be that great. For SATA, 3ware
> seems to be the best choice. In general, adaptec SCSI do quite
> well, they provide in addition tools coming as rpm if you want.
> Just be sure to check if the model whatever manufacturer is really
> supported with your distro/kernel, if compiling a new
> kernel/driver isn't an option for you.
> Did you get any answer on the license request, we were talking
> about here some weeks ago?

A local lady representative from redhat emailed me to say that she had
been trying to contact me, but I never had a phone call from her (nor
had she phoned me when I was out, to my knowledge). I emailed back to
say that email would be fine and there was no need to phone. I'll
remind her.