I have been fighting the urge of replying to this because I know I will
get some yellins but here goes.
The described scenario is reproducible on PERC cards when operating in
a noisy environment. Bad signal integrity will always get you and
eventually knock some drives offline. The described mec
Steve Shockley wrote:
> RedShift wrote:
>> Anyone got any similar experiences with hardware RAID cards? Hardware
>> RAID has always been misery for me.
>
> I've had two instances where older Adaptec RAID cards had a disk failure
> and then reverted to a week-old copy of the data. I'm not quite
RedShift wrote:
Anyone got any similar experiences with hardware RAID cards? Hardware
RAID has always been misery for me.
I've had two instances where older Adaptec RAID cards had a disk failure
and then reverted to a week-old copy of the data. I'm not quite sure
how that's possible, but hav
> Anyone got any similar experiences with hardware RAID cards? Hardware
> RAID has always been misery for me.
I've never lost data under RAIDframe - 3 years plus using cheap SATA
gear and featuring a number of unplanned hard boots and flaky air
conditioning.
Can't say the same for a certain hardw
Greg Oster wrote:
I worry more about a hardware RAID card forgetting its configuration
after a power outage than I do about parity checking in the
background :) ("What do you mean these 14 disks in this 2TB hardware
RAID array are now all 'unassigned'!?!?!?!". That wasn't a fun day.)
Rea
On Fri, 28 Sep 2007, Matt wrote:
> Brian A. Seklecki schreef:
>
> As for the suggestion of hardware raid - unfortunately this is a live
> server. If I migrate it to another machine I will definitely try
> hardware raid
> I know it is a lot faster but would that solve the parity problem on
> boot c
> I know it is a lot faster but would that solve the parity problem on
> boot completely? 'man bio' doesn't seem to answer that.
For a variety of reasons, hardware raid controllers handle ungraceful
shutdown better -- onboard batteries for the HBA's RAM/Cache, etc.
Hardware RAID almost never goe
Matt writes:
>
> As for the suggestion of hardware raid - unfortunately this is a live
> server. If I migrate it to another machine I will definitely try
> hardware raid
> I know it is a lot faster
Really? :) There is no guarantee that a hardware RAID is faster than
a software RAID, or vice-v
"Brian A. Seklecki" writes:
> raid(4) hasn't been touched in a while (years), so short answer: No.
>
> NetBSD is still actively committing to it, though, and has functional
> background parity recalculation.
Just to be clear here: the background parity checking in NetBSD as of
today is function
Brian A. Seklecki schreef:
raid(4) hasn't been touched in a while (years), so short answer: No.
NetBSD is still actively committing to it, though, and has functional
background parity recalculation.
I understand there is interest in replacing RAIDFrame instead of
resynchronizing the subtree.
raid(4) hasn't been touched in a while (years), so short answer: No.
NetBSD is still actively committing to it, though, and has functional
background parity recalculation.
I understand there is interest in replacing RAIDFrame instead of
resynchronizing the subtree.
In the mean time, find a
On 9/25/07, Matt <[EMAIL PROTECTED]> wrote:
> I'm running a RAID1 mirror on OpenBSD 4.1 (webserver)
> On a power failure the parity becomes dirty and needs rewriting, which
> results in > 1.5 hours 'downtime'.
> Is it safe to background this in /etc/rc or is that a no-no?
>
> I found a reference th
I'm running a RAID1 mirror on OpenBSD 4.1 (webserver)
On a power failure the parity becomes dirty and needs rewriting, which
results in > 1.5 hours 'downtime'.
Is it safe to background this in /etc/rc or is that a no-no?
I found a reference this was possible/safe on-list but it was a) 2003
and
13 matches
Mail list logo
