lkml.org 
[lkml]   [2000]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 2.2.10-14 i686 SMP: IDE RAID-5 array hangs on mount
In <388C7A32.1988F5E0@mit.edu> Adam C Powell IV (hazelsct@mit.edu) wrote:
AI> Khimenko Victor wrote:

>> 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> Cool, then maybe they'll be in 2.2.15?

Ask Cox, not me :-) Since Cox is RedHat's employee it looks VERY weird to me
that RedHat's kernel and "official" Cox's kernel are two such different beasts.
Anyway, as 2.2.15 turned out to be "quick bugfix release" (AGAIN!) RAID 0.90
will not be integrated. If it'll be integrated in 2.2.x series at all...

>> 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 :-)

AI> Okay, then RAID amateurs who use any other distro (okay, perhaps SuSE and TurboLinux
AI> have the patches...), or RAID amateurs who download the latest stock kernel. When
AI> 2.2.15 comes out, should such amateurs be expected to know to wait for RedHat 6.2 (or
AI> SuSE whatever)?

They should wait for Ingo to release RAID 0.90 patch for 2.2.15 I think :-)
At least knfsd (not know about RAID) was sheduled for inclusion in 2.2.15 but
now when 2.2.15 is "quick bug-fix release" (AGAIN!) it looks like KNFSD and
RAID will be postponed once again :-/

AI> Thank you very much for the help, I appreciate it very much. But I do still think
AI> there needs to be some change in the way RAID is done in the stable kernel. Either it
AI> should be patched to use RAID 0.90, or there should be VERY LOUD WARNINGS in many
AI> places, including drivers/block/Config.in, Documentation/Configure.help and
AI> Documentation/md.txt (and in Debian, in /usr/share/doc/raidtools/DO-NOT-USE), telling
AI> people not to expect what's there to work.

They can expect it to work. And it even works. Sometimes.

AI> I cannot tell you how frustrated this has made me over the last three months, when
AI> kernel after kernel just failed. I tried different IDE options, I tried different
AI> compilers, and each time my RAID array took more than seven hours to ckraid --fix
AI> (which was not automatic in Debian potato until about a month ago, so the downtime was
AI> often a lot longer), during which /home for my entire research group- including
AI> everyone's web pages- was unavailable. After the third or fourth failure, I went to
AI> the debian-user mailing list, where the advice given was to just use gcc 2.7.2, which
AI> of course did nothing for me, and I asked again and nobody had any clue.

Looks like you just asked in wrong place :-) It's typical situation in fact:
there are LOTS of patches floating around. But they will be added in kernel
only when they looks "good enough". Sometimes conclusion is that "it's good
stuff and it should be added... in next version of kernel - since there are to
many changes to make such a pile of changes suitable for inclusion in stable
kernel". Even if for most peoples RAID 0.90 works MUCH better then default
RAID from stock linux kernel.

AI> I've been enjoying Linux for long enough on a wide enough variety of platforms- and
AI> have had bad enough experiences with NT (really bad, hate it, hate it, hate it!)- that
AI> switching has not been an option. But the value of the hours and hours of lost time-
AI> several days in total- made me *very* seriously reconsider this- this has been almost
AI> as bad as the NT nightmares. It probably would have even been worth the extra price
AI> of Solaris/Sparc!

AI> Linux can be one of two things:

AI> 1. A professional system whose stable kernels just work.
AI> 2. A hobbyist/geek system which requires patches to make things work, and doesn't
AI> even say so anywhere in the documentation, one must "just know" these things.

AI> My impression has been that Linux aims for #1, but it seems I am wrong, or at the very
AI> least, the RAID policy has been pure #2.

Not at all. It was more like "RAID 0.90 looks great but it's not yet clear if
improvements are really big enough to add incompatibilities in stable kernel
series". Only when it's clear that applaying patch is "Good Thing(tm)" patch
is applied. All other patches (and there are LOTS of them: RAID patches, KNFSD
patches, IDE patches, etc) should be VERY rigourously tested before they will
be included in linux kernel. ESPECIALLY in stable version. As Linus said
"I prefer to have a known bug that will eventually get fixed than an ugly
solution that will hide it forever." I hope you'll undertood this position.
If you call this "hobbyist/geek system" - be so, swicth to other system.

AI> If it is about to be fixed, that's great, but for future reference, quality
AI> control issues like this matter a whole lot to a great many people.

Unfortunatelly "quality" means different things for different peoples :-/

AI> I don't expect it to be perfect- we are human after all- but where
AI> there are known problems or unmaintained sections of the kernel, please
AI> document them far and wide.

It WAS documented. In linux-kernel mailing list archives. Unfortunatelly it's
THE ONLY more or less complete documentation for kernel :-/ Even here some
things are not documented but all other sources are even less complete.

AI> Still disappointed, but grateful for the help!





-
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.122 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site