In <3888CD6E.29D407EB@mit.edu> Adam C Powell IV (hazelsct@mit.edu) wrote:
AI> Apologies for the delay, I've been having some email trouble. Future followups
AI> will be a lot quicker.
AI> Khimenko Victor wrote:
>> In <3883285B.450536A@mit.edu> Adam C Powell IV (hazelsct@mit.edu) wrote:
>> > Greetings,
>>
>> > I have a RAID-5 array across 10 GB partitions on four 17 GB IDE drives
>> > at hda-d, and a RAID-0 array across 5 GB partitions on the same drives,
>> > on a dual-Celeron ABIT BP6 motherboard (haven't installed the recent
>> > BIOS upgrade).
>>
>> > I've built SMP kernels from 2.2.10 and 2.2.13 source with gcc-2.95, and
>> > then 2.2.13 and 2.2.14 with gcc-2.7.2.3, all using the standard Debian
>> > .config except 686 and SMP (well, approximately the Debian 2.2.13 config
>> > for 2.2.14).
>>
>> That is: you are using broken RAID implementation and expect it to work
>> somehow ?
AI> Uh, there's a broken RAID implementation in a stable kernel?
Not exactly "broken". More like "unmaintained". It works for some peoples but
there are LOTS of problems with it :-/ And noone bother to fix them since
there are exist version 0.90 :-)
>> > For all of these kernels, the machine always hangs while mounting the
>> > RAID-5 array. It never hangs while mounting the RAID-0 array, which
>> > happens to come before it. And it never hangs under the non-SMP 386
>> > Debian kernel images.
>>
>> > Are there any known races which got into 2.2.14? I haven't yet tried
>> > 2.2.15-pre, is there any reason to believe it might solve the problem?
>>
>> It will not solve problem. RAID as it is in 2.2.x kernels us unstable and
>> unmaintained. You REALLY should use raid patches. There are some
>> incompatibilities with 2.2.x RAID implementation and latest RAID patches
>> and thus it's not going in 2.2.x but if you need working raid (and you do
>> hot have one) you SHOULD NOT use stock 2.2.x RAID. Use one from
>> http://people.redhat.com/mingo/raid-2.2.14-B1
AI> Hmm, I sense a contradiction here: 2.2.x RAID is incompatible with the latest
AI> RAID patches and so will stay in, but 2.2.x RAID is unstable and unmaintained.
AI> If you don't mind my asking, what kind of logic motivated that policy?
1. If you are lucky and have working RAID based on stock 2.2.x (for example
RAID 0 :-) you should be able to upgrade to 2.2.14 without big hassle.
So upgrade to RAID 0.90 in mainstream kernel posponed to 2.4 ...
2. RAID 0.90 need some changes in some important kernel structures and such
changes will affect even users without RAID.
RedHat 6.1 includes RAID patches anyway so I'm not sure if 2. still can be
considered seriously.
AI> But seriously. So what you're telling me is that I need to back up all of my
AI> data, install a patched kernel (and Debian raidtools2), and completely wipe and
AI> reinstall the RAID arrays, right? Are there any tools to translate old RAID
AI> arrays into new ones?
AFAIK you do not need to backup data and reinstall it (I can be wrong here).
You should install new RAID tools and accomodate configuration files but
actual contents of RAID array do not need to be reinstalled.
AI> Please seriously consider the attached patch for 2.2.15. It will save a lot of
AI> time and grief for RAID amateurs like myself.
RAID amateurs will use RedHat 6.1 with patched kernel :-)
>> P.S. Hmm. Stefan Monnier said back in september "Every serious NFS user uses
>> the patched knfsd, and every serious raid user uses the new raid code". Looks
>> like he was wrong after all :-/
AI> I set this up in August, so I'm not covered by this. :-) And I think from the
AI> above you can determine that I hardly qualify as "serious"- it took me three
AI> months to build my first kernel for the machine! The only reason I'm here on
AI> the vger list is that in spite of multiple posts to debian-user since late
AI> November, nobody there gave me an answer even half as helpful as yours!!
AI> Quite disappointed,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:27 EST