Help, my disk array has one dead member

[Kevin O'Gorman]

On Sat, Mar 25, 2017 at 5:58 AM, Xen <list at xenhideout.nl> wrote:

> Kevin O'Gorman schreef op 24-03-2017 3:26:
>
>> Well, okay, this should be my "real" last word.
>>
>> I had no idea what to expect.  But I put my 3 drives into USB3 drive
>> docks (my 3rd one arrived today).  mdadm is now projecting RAID5 will
>> be finished in 4.6 days.  Egad!
>> I guess it makes sense.  7.4 Tib to read, 3.7Tib of parity to write.
>>
>
> In general opinions are not great about RAID 5.
>
> I once ran a RAID 10 but it was on a crappy AMD controller with more/less
> crappy software.
>
> But there are some that prefer RAID 10 over RAID 5 because of simplicity
> and speed.
>
> The extra disk cost is worth the advantage to them.
>
> I think it made 512-byte blocks.  Would anything go faster if I
>> changed that or any of the other defaults?
>>
>
> I really don't know but that would not be very good. A stripe should be
> between ... well what do I know. I would suspect you'd want at least 4k,
> but these can cause rewrites... I don't know. Maybe someone else can
> answer. Sector per sector writes are just awfully slow you know...
>
> I wonder how many times you'd actually write less than 4k...
>
> Regardless.
>
> Ideally RAID 10 has the throughput of a stripe and the access times of a
> mirror. It's not extremely failsafe but if the "right" drives fail you can
> handle 2 drive failures.
>
> Well anyway.
>
> Not something you can do right now right :p.
>

Fortunately, I think RAID5 is a good fit for my use-case.  Overall, it's
compute-intensive, not so much DB-intensive.  My requirement of the
database is that it be large and reliable, not so much fast.  I tend to be
working on a small part of the data at a time.  I have compute tasks that
run for days with no disk activity at all.

-- 
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20170327/a7d2f776/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 441 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20170327/a7d2f776/attachment.gif>