Re: [gentoo-user] Re: SDD strategies...

[Rich Freeman]

On Wed, Mar 18, 2020 at 9:49 AM antlists <antlists@××××××××××××.uk> wrote:
>
> On 17/03/2020 14:29, Grant Edwards wrote:
> > On 2020-03-17, Neil Bothwick <neil@××××××××××.uk> wrote:
> >
> >> Same here. The main advantage of spinning HDs are that they are cheaper
> >> to replace when they fail. I only use them when I need lots of space.
> >
> > Me too. If I didn't have my desktop set up as a DVR with 5TB of
> > recording space, I wouldn't have any spinning drives at all.  My
> > personal experience so far indicates that SSDs are far more reliable
> > and long-lived than spinning HDs.  I would guess that about half of my
> > spinning HDs fail in under 5 years.  But then again, I tend to buy
> > pretty cheap models.
> >
> If you rely on raid, and use spinning rust, DON'T buy cheap drives. I
> like Seagate, and bought myself Barracudas. Big mistake. Next time
> round, I bought Ironwolves. Hopefully that system will soon be up and
> running, and I'll see whether that was a good choice :-)

Can you elaborate on what the mistake was?  Backblaze hasn't found
Seagate to really be any better/worse than anything else.  It seems
like every vendor has a really bad model every couple of years.  Maybe
the more expensive drive will last longer, but you're paying a hefty
premium.  It might be cheaper to just get three drives with 3x
redundancy than two super-expensive ones with 2x redundancy.

The main issues I've seen with RAID are:

1. Double failures.  If your RAID doesn't accommodate double failures
(RAID6/etc) then you have to consider the time required to replace a
drive and rebuild the array.  As arrays get large or if you aren't
super-quick with replacements then you have more risk of double
failures.  Maybe you could mitigate that with drives that are less
likely to fail at the same time, but I suspect you're better off
having enough redundancy to deal with the problem.

2.  Drive fails and the system becomes unstable/etc.  This is usually
a controller problem, and is probably less likely for better
controllers.  It could also be a kernel issue if the
driver/failesystem/etc doesn't handle the erroneous data.  I think the
only place you could impact this risk is with the controller, not the
drive.  If the drive sends garbage over the interface then the
controller should not pass along invalid data or allow that to
interface with functioning drives.

This is one of the reasons that I've been trying to move towards
lizardfs or other distributed filesystems.  This puts the redundancy
at the host level.  I can lose all the drives on a host, the host, its
controller, its power supply, or whatever, and nothing bad happens.
Typically in these systems drives aren't explicitly paired but data is
just generally pooled, so if data is lost the entire cluster starts
replicating it to return redundancy, and that rebuild gets split
across all hosts and starts instantly and not after you add a drive
unless you were running near-full.  One host replicating one 12TB
drive takes a lot longer than 10 hosts replicating 1.2TB each to
another host in parallel as long as your network switches can run at
full network capacity per host at the same time and you have no
bottlenecks.

-- 
Rich