Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Jan 2012 23:38:14 +0200
From:      Alexander Motin <mav@FreeBSD.org>
To:        Vinny Abello <vinny@abellohome.net>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: FreeBSD 9.0 and Intel MatrixRAID RAID5
Message-ID:  <4F15EA46.7000600@FreeBSD.org>
In-Reply-To: <4F15E992.4080301@abellohome.net>
References:  <CA%2BD9QhtZpPK%2Bqv%2BNg4b2Mc6wgwcdumiMH3LS-9e1dHHVe7Jp%2BQ@mail.gmail.com> <mailpost.1326821700.5568126.14545.mailing.freebsd.stable@FreeBSD.cs.nctu.edu.tw> <4F15E243.2030000@FreeBSD.org> <4F15E992.4080301@abellohome.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 17.01.2012 23:35, Vinny Abello wrote:
> On 1/17/2012 4:04 PM, Alexander Motin wrote:
>> On 17.01.2012 19:03, Vinny Abello wrote:
>>> I had something similar on a software based RAID controller on my Intel S5000PSL motherboard when I just went from 8.2-RELEASE to 9.0-RELEASE. After adding geom_raid_load="YES" to my /boot/loader.conf, it still didn't create the device on bootup. I had to manually create the label with graid. After that it created /dev/raid/ar0 for me and I could mount the volume. Only thing which I've trying to understand is the last message below about the integrity check failed. I've found other posts on this but when I dig into my setup, I don't see the same problems that are illustrated in the post and am at a loss for why that is being stated. Also, on other posts I think it was (raid/r0, MBR) that people were getting and trying to fix. Mine is (raid/r0, BSD) which I cannot find reference to. I have a feeling it has to do with the geometry of the disk or something. Everything else seems fine... I admittedly only use this volume for scratch space and didn't have anything important st

> or
>> ed
>>>    on it so I wasn't worried about experimenting or losing data.
>>>
>>> ada0 at ahcich0 bus 0 scbus2 target 0 lun 0
>>> ada0:<WDC WD4000YR-01PLB0 01.06A01>   ATA-7 SATA 1.x device
>>> ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes)
>>> ada0: Command Queueing enabled
>>> ada0: 381554MB (781422768 512 byte sectors: 16H 63S/T 16383C)
>>> ada0: Previously was known as ad4
>>> ada1 at ahcich1 bus 0 scbus3 target 0 lun 0
>>> ada1:<WDC WD4000YR-01PLB0 01.06A01>   ATA-7 SATA 1.x device
>>> ada1: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes)
>>> ada1: Command Queueing enabled
>>> ada1: 381554MB (781422768 512 byte sectors: 16H 63S/T 16383C)
>>> ada1: Previously was known as ad6
>>>
>>> GEOM_RAID: Intel-8c840681: Array Intel-8c840681 created.
>>> GEOM_RAID: Intel-8c840681: Disk ada0s1 state changed from NONE to ACTIVE.
>>> GEOM_RAID: Intel-8c840681: Subdisk ar0:0-ada0s1 state changed from NONE to ACTIVE.
>>> GEOM_RAID: Intel-8c840681: Disk ada1s1 state changed from NONE to ACTIVE.
>>> GEOM_RAID: Intel-8c840681: Subdisk ar0:1-ada1s1 state changed from NONE to ACTIVE.
>>> GEOM_RAID: Intel-8c840681: Array started.
>>> GEOM_RAID: Intel-8c840681: Volume ar0 state changed from STARTING to OPTIMAL.
>>> GEOM_RAID: Intel-8c840681: Provider raid/r0 for volume ar0 created.
>>> GEOM_PART: integrity check failed (raid/r0, BSD)
>>>
>>> Any ideas on the integrity check anyone?
>>
>> It is not related to geom_raid, but to geom_part. There is something wrong with your label. You may set kern.geom.part.check_integrity sysctl to zero do disable these checks. AFAIR it was mentioned in 9.0 release notes.
>
> Thanks for responding, Alexander. I also found that information about that sysctl variable, however I was trying to determine if something is actually wrong, how to determine what it is and ultimately how to fix it so it passes the check. I'd rather not ignore errors/warnings unless it's a bug. Again, I have no data of value on this partition, so I can do anything to fix it. Just not sure what to do or look at specifically.

First thing I would check is that partition is not bigger then the RAID 
volume size. If label was created before the RAID volume, that could be 
the reason, because RAID cuts several sectors off the end of disk to 
store metadata.

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F15EA46.7000600>