[CentOS-docs] Updated How to Setup a Software RAID on CentOS 5

Thu Apr 30 16:39:47 UTC 2009
Ned Slider <ned at unixmail.co.uk>

R P Herrold wrote:
> On Wed, 29 Apr 2009, Phil Schaffner wrote:
>>> R P Herrold wrote:
>>>> On Wed, 29 Apr 2009, Ned Slider wrote:
>>>>> unknown prior wrote ...
>>>>>   There's always going to be an argument about whether to 
>>>>> put /boot and swap on RAID.  It's all about performance 
>>>>> most of the time being slightly better versus stability 
>>>>> in the event of device failure.
>>>> I can't think of a good argument for not having /boot on the raid1.
>>> Then you do not support it, and see the recurring support load
>>> in #centos -- we get this load all the time.
>     ...
>> That's pretty much what the article started with if you follow the long
>> history of the first thread on the contribution, but the consensus of
>> the people who commented was overwhelmingly in favor of /boot on RAID1,
>     ...
> My response was simply in reply to the 'I can't think of a 
> good argument' comment by 'Ned Slider'.
> To respond to 'the consensus ... overwhelmingly' remark, the 
> mice also overwhelmingly voted to bell the cat.  Counting 
> noses does not make a bad answer more correct; using raid 
> rather than flat RO /boot partitions is still less robust

Well it seems you are alone in your view (at present, on this list). I 
have yet to see a convincing argument to change my opinion to not place 
/boot on a software RAID1 where one has chosen to use software RAID1.

You state 'putting /boot on raid adds complexity' - I disagree in this 
case (for software raid1), it removes the additional complexity of 
having to manually resync /boot if it's *not* on the software RAID1 
every time it's updated, and that appears to be the opinion held by 
others (and the very reason the page was created in the first place). 
Why add complexity - why not let the raid do the work for you. If either 
drive fails the system will still boot and the faulty drive can be replaced.

More robust, but with additional complexity doesn't necessarily make a 
better solution for new (inexperienced) users. Best practices are 
usually derived through discussion and consensus, something I believe 
this thread is striving to achieve.

>> so that's where it is now.  Would be glad to add a footnote 
>> with your POV, or feel free to do so yourself.
> No, when it irritates me enough that the clueless newbies who 
> don't read and don't research are not helped by yet another 
> writeup not to read, and keep coming back for spoons, I may 
> add a Method B subsection.  Or more likely ignore what I 
> consider a bad support method and point to our rebuild of 
> upstreams doc's

Upstream docs appear to advocate *exactly* what the current Wiki page 
describes (as do the CentOS docs):


> I remain unconvinced that replicating documentation, and 
> adding places for entropy to rot in a wiki is a win.  I'd 
> upstream the change, instead, as there is NO CentOS specific 
> aspect here.

I guess the point here is people don't read the docs but might 
search/read the Wiki, and we are able to amend/add to the Wiki were we 
are unable to do so in upstream derived docs.