Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Mar 2007 08:52:15 -0700
From:      "Steve Franks" <stevefranks@ieee.org>
To:        "Toomas Aas" <toomas.aas@raad.tartu.ee>
Cc:        questions@freebsd.org
Subject:   Re: Converting from ata-raid to gmirror
Message-ID:  <539c60b90703190852s70e2170di49b92de4a41b8e4f@mail.gmail.com>
In-Reply-To: <45FDAA18.1080203@raad.tartu.ee>
References:  <45BFB6A1.9080200@raad.tartu.ee> <45FDAA18.1080203@raad.tartu.ee>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On 3/18/07, Toomas Aas <toomas.aas@raad.tartu.ee> wrote:
> On January 30th, I wrote:
>
> > I'm currently running FreeBSD 6.2-RELEASE (amd64) on a system based on
> > Intel SE7230NH1-E motherboard, which has Intel ICH7R integrated
> > softraid. The machine has two 500 GB drives which are configured as
> > RAID1 in BIOS. Unfortunately, this setup seems to have some stability
> > issues which I can't figure out how to solve. Specifically, when the
> > storage subsystem is put under heavy load (such as doing nightly
> > backups) the kernel starts spitting out horrible error messages such as:
> >
> > FAILURE - out of memory in ata_raid_init_request
> > g_vfs_done():ar0s1f[WRITE(offset=8091172864, length=16384)]error = 5
> > FAIg_vfs_done():ar0LURE - out of memsory in ata_raid_1init_reqfu[eWsRItTE(o
> > ffset=8091F1A8I9LU2R4E8 ,-  oleuntg tohf= 16m3e8m4o)ry]e rirno ra t=a 5
> > _raid_init_requestg
> >  vfs_done():ar0s1f[WRITE(offsFAeItL=UR8E0 9-1 2o05u6t3 2o,f
> > lmeengmtoh=ry1 6i3n8 4a)t]ae_rrraoird _=in i5t
> >
> > If it looks like garbage, then yes, this is how it appears in
> > /var/log/messages. I'm seriously afraid that similar corruption is
> > sneaking into important user files.
> >
> > Only thing I can think of is converting this setup from BIOS-based RAID
> > to gmirror. This would involve, I think, modifying /etc/fstab so that it
> > references ad4 instead of ar0, then permanently breaking the mirror in
> > BIOS, booting up the system with single disk and then basically
> > following the gmirror chapter in the handbook. Correct?
> >
> > I'm also a little uncertain about "permanently breaking the mirror"
> > part. I've read all the motherboard and LSI docs I can find and this
> > topic isn't covered anywhere.
>
> Well, finally I could summon up enough courage to perform this procedure
> on a production server (such as it is). To break the mirror, I just went
> to motherboard BIOS (not the BIOS-based RAID utility) and changed the
> 'Configure SATA as' setting from 'RAID' to 'IDE'. Generally everything
> seems to have gone OK. The system now runs from /dev/mirror/gm0, which
> consists of ad4 and ad6. However, the kernel still sees the old ar0
> array and complains that it's broken. Do I care, or should I just remove
> 'device ataraid' from kernel configuration?
>
> kernel: ar0: WARNING - mirror protection lost. RAID1 array in DEGRADED mode
> kernel: ar0: 476772MB <LSILogic v3 MegaRAID RAID1> status: DEGRADED
> kernel: ar0: disk0 READY (master) using ad4 at ata2-master
> kernel: ar0: disk1 DOWN no device found for this subdisk
>
> --
> Toomas
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
>

I'm just getting into this myself as well, but from previous people
who've helped me, I've come to understand that most motherboard 'raid'
controllers are not tru hardware raid, just a fancy wrapper around
software raid, and they do pretty much exactly the same thing as
gmirror - write a special metadata tag near the end of the disk with
the info on the mirror.  This is what ataraid sees that causes it to
find 'ar0' - delete that metadata from the disk, and ar0 will go away.
 Possibly there is an extra slice with a couple of blocks at the end
of the disk?  That's about the extent of my knowledge...

Steve



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?539c60b90703190852s70e2170di49b92de4a41b8e4f>