Bristol Digest, Vol 593, Issue 2

Send Bristol mailing list submissions to
bristol@mailman.lug.org.uk

To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.lug.org.uk/mailman/listinfo/bristol
or, via email, send a message with subject or body 'help' to
bristol-request@mailman.lug.org.uk

You can reach the person managing the list at
bristol-owner@mailman.lug.org.uk

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bristol digest..."


Today's Topics:

1. Re: Linux Raid (Alex Butcher)


----------------------------------------------------------------------

Message: 1
Date: Wed, 11 Mar 2015 10:44:24 +0000 (GMT)
From: Alex Butcher <lug@assursys.co.uk>
To: Huw Morgan <huw@cleevemill.net>
Cc: Bristol and Bath Linux User Group <bristol@mailman.lug.org.uk>
Subject: Re: [bristol] Linux Raid
Message-ID:
<alpine.LRH.2.11.1503111031410.22955@zlgugi.of5.nffheflf.cev>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

Hi Huw

[Cc'ed to the list for education of others, archival and input from anyone
else who feels like giving their two penneth worth]

On Wed, 11 Mar 2015, Huw Morgan wrote:

> Really sorry to bother you but I've had a few glitches with the Linux raid
> on my mail server and you seemed rather knowledgeable ....
>
> So, I set it up as you suggested ( i.e. a new install, of Ubuntu, letting
> the installer handle the raid set up - I used 3 x 2TB drives, with md0 - 4GB
> Swap, md1 - 1.8TB main partition and md2 -180GB spare partition - I mirrored
> this on drives a & b, designating drive c as a 'spare' (I assumed Linux
> would use drive c as the drive to rebuild the mirror on if either a or b
> failed)

I've never configured a RAID 1 array with a pre-designated spare. I suspect
that's an unusual configuration; spares are usually used in combination with
parity RAID levels.

> - so far so good, all looked okay - webmin showed all three partitions
> clean. I then built my mail server and tested that.
>
> I then powered down and to test the raid , removed the sata cable to drive
> one and rebooted - all good. Powered down again, re-attached the sata cable
> and rebooted. I checked webmin and it said that the raid on a & b was
> degraded and rebuilding - which I assumed was what it should show, so I let
> that run it's course. All good. I then tried removing sata cable from disk 2
> - system still booted fine - so I thought - job done !
>
> A couple of days later I checked webmin and found that the system had
> somehow moved to using drive c only ! (the one I designated as a spare) ???
> I (using console) and mdadm reattached drive b to the raid ( on md0,1&2)
> and it rebuilt itself - hmm ?
>
> Next day, I powered down to insert a bit more RAM, when I rebooted I checked
> webmin and saw that on partition md2, drive b had become detached ( the
> other 2 partitions were still good - i.e. drives c & b ) so, again using
> mdadm I re-attached drive b to md2.
>
> I guess my question is, if a normal reboot manages to detach a drive from
> the raid, can I rely on the raid system at all. Am I/Have I done something
> wrong - system all works fine but if I can't rely on the raid, it seems a
> bit pointless

Reboots shouldn't in themselves cause drives or partitions to drop out of
arrays. So you've probably got a problem of some kind or another.

SATA connectors are horrible, unlatched ones especially. They're prone to be
easily dislodged. They're only rated for 50 insertion cycles. Are you
using cables with latched or unlatched connectors? Are you absolutely
certain that you didn't dislodge a cable (or rather, checked all of them
were firmly connected afterwards!) when fitting the memory?

What make/model of drives are you using? If they're not RAID/NAS-specific
models, then errors can cause extended error recovery behaviour, which can
cause IO request timeouts in the driver, which then in turn cause the RAID
layer to believe the drive has failed completely and so it kicks the
drive/partition out entirely. This is the reason for TLER on
RAID/NAS-specific models.

> I would appreciate your thoughts
>
> Regards
>
> Huw Morgan

HTH,
Alex

>
>
>
> -----Original Message-----
> From: Alex Butcher [mailto:lug@assursys.co.uk]
> Sent: 05 March 2015 22:15
> To: huw@cleevemill.net
> Cc: Bristol and Bath Linux User Group
> Subject: Re: [bristol] Linux Raid
>
> On Thu, 5 Mar 2015, Huw Morgan wrote:
>
>> I'm new to the user group and pretty new to Linux too although I've
> been
>> using it blindly for about 10 years ! I've just built myself a mail
> server
>> on Ubuntu 14.04 using Postfix and Courier and whilst it seems to be
> working
>> well, I have started worrying about data security.
>>
>> To this end I am planning to re-build it with a Raid setup.
>
> Good idea.
>
> But remember that RAID isn't a substitute for backups. Moving on...
>
>> A lot of googling has lead me to consider using Linux raid via mdadm
>> (rather than the 'so-called' hardware BIOS raid built into my HP
> Proliant
>> ML110 G5 server).
>
> Actually, assuming the HP RAID implemention is like Intel's Rapid Storage
> Technology (aka Matrix RAID aka fakeraid), there shouldn't be much
> difference. Essentially, all these fakeraid solutions consist of are a)
> BIOS kludges to allow booting from RAID volumes (and use of DOS, I
> suppose!)
> and b) drivers which implement RAID, even if the OS doesn't (this is
> particularly relevant for Windows where certain RAID levels are only
> available in 'Enterprise' versions).
>
> The most significant advantage of Linux md software RAID is that if the host
> machine fails, you can remove the discs to another Linux machine and
> assemble the array (assuming the kernel has md RAID support compiled in!)
> regardless what make/model of controller(s) they're plugged into.
>
> Proper hardware RAID has the advantage of providing tried-and-tested hotswap
> and battery/flash/super-capacitor backed cache for enhanced performance and
> data integrity. Very spendy!
>
>> Ideally I would like the ability to hot swap drives.
>
> If your BIOS is configured to present SATA drives as AHCI, you /should/ be
> able to hotswap. In practice, I'd avoid it - too many untested combinations
> could lead to surprises!
>
> If you're insistent on hotswap, you'll probably also want hotswap caddies to
> avoid knocking/dislodging/damaging other drives. Something like:
>
> <http://www.startech.com/HDD/Mobile-Racks/Hot-Swap-SATA-SAS-Backplane-RAID
> -Bays-3-Hard-Drive-Mobile-Rack~SATSASBAY3BK>
> <http://www.amazon.co.uk/s/ref=sr_nr_n_0?fst=as%3Aoff&rh=n%3A340831031%2Cn
> %3A430435031%2Ck%3Amb996&keywords=mb996&ie=UTF8&qid=1425573816&rnid=340832
> 031>
>
> Spendy!
>
>> My questions centre around - what raid solution should I choose
>
> I've been using Linux md RAID at home for over a decade. It's pretty good
> these days.
>
> I've recently set up an Intel RST array, and it seems broadly equivalent,
> but some of the details of its operation (e.g. how it handles a read error
> on one device in an array) when using the Windows drivers are opaque.
>
> These days, I use and recommend Western Digital Red NAS drives for mirror
> and parity RAID arrays (see the Features->NASware tab of
> <http://www.wdc.com/en/products/products.aspx?id=810&utm_source=WD%20Red%2
> 0redirect&utm_medium=collateral&utm_content=en&utm_campaign=product#Tab2&T
> ab9>
> for why - in brief, TLER and command completion). Note that the features of
> such drives work against you in single drive or stripe RAID arrays, so don't
> do that.
>
> I always use hardware RAID with Western Digital RAID Edition drives in
> professional settings.
>
>> and should I use a separate boot disk ?
>
> No need, really, providing you're booting from RAID 1 or RAID 10.
>
>> I wondered if there was some helpful soul in the local Linux
>> community who would spare the time to educate me
>
> <http://linux.die.net/man/4/md> worth reading, also
> <https://wiki.archlinux.org/index.php/RAID>
>
>> Huw Morgan
>
> HTH,
> Alex
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.5645 / Virus Database: 4306/9274 - Release Date: 03/11/15
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.5645 / Virus Database: 4306/9274 - Release Date: 03/11/15
>
>



------------------------------

_______________________________________________
Bristol mailing list
Bristol@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/bristol

End of Bristol Digest, Vol 593, Issue 2
***************************************