All these drives were on hardware RAID cards it seems, is it feasible to do without them?
I recommend using the RAID card as an HBA (JBOD), turn on the fast path, and use software that can share multiple devices evenly.
SSDs: A gift and a curse
61–70 of 99 posts
Re: SSDs: A gift and a curse
#62Parts of this sound more like hardware RAID controller issues than SSD issues, which is why I typically avoid hardware RAID in production environments unless there's a specific reason for it. RAID controllers tend to be buggy pieces of shit, usually implementing some RAID method that's more-or-less proprietary and unique even between different RAID cards from the same vendor (meaning that if your RAID controller fail…
A modern filesystem, like ZFS, will protect against random bit errors. Raid 5/6 are still not appropriate for todays large disk sizes, but raidz3 (three parity disks instead of one or two) is.
Depending on the size of the array, however, even having three parity disks is likely insufficient. Using parity instead of mirroring (or a mirroring+striping approach like RAID10) - i.e. RAID3, RAID5/6, and (IIRC) RAID-Z - assumes that disk failures are rare; in reality, the probability of subsequent disk failures increases significantly once one disk failure occurs (which makes sense: unless you're mixing/matching vendors (which has its own problems), you're probably buying a lot of disks at the same time, probably from the same or similar batches, and therefore with the same failure tendencies). For things like SANs and other large arrays of disks (where the use of ZFS is more prevalent), the difference in safety between two and three parity disks is negligible. You could keep adding more and more, but at that point, you might as well just use RAID10. If you're running a smaller array, you also might as well just use RAID10 (or RAID1 if you only have 2 disks in the array, but that's playing it dangerous for the same reason why RAID5/6/Zx is playing it dangerous).
This is part of the reason why ZFS supports a variety of different RAID and RAIDlike configurations. If you're using a pure-ZFS approach, I'd strongly recommend having zpool create striped mirrors (i.e. RAID10) in order to get the benefits of ZFS' data checksumming and not be susceptible to such a high risk of data loss.
Re: SSDs: A gift and a curse
#63Parts of this sound more like hardware RAID controller issues than SSD issues, which is why I typically avoid hardware RAID in production environments unless there's a specific reason for it. RAID controllers tend to be buggy pieces of shit, usually implementing some RAID method that's more-or-less proprietary and unique even between different RAID cards from the same vendor (meaning that if your RAID controller fail…
To expand: in my 20-year experience, no small-computer RAID 5/6 controller I have had experience with has ever saved any data, ever. All failures are hard and non-recoverable. Which begs the question: why use them at all? I mirror only.
I have seen data recovery. Once. 22 years into my career, and it was still a home system. Which I believe proves your point.
Re: SSDs: A gift and a curse
#64I bought two consumer intel.. 80gb? Ssds. They both lasted less than a year before they stopped posting or allowing a system boot on separate devices.
The 850 pro is ok, but it's slowed down a lot lately. Might be an OS thing, which i doubt.
All in all i keep a redundant backup on old school hdds too since the failure rate of SSDs isn't so great in my experiences so far.
Anyone try one of the newer M2's yet? Or i think i mean the pci-E types?
Re: SSDs: A gift and a curse
#65Parts of this sound more like hardware RAID controller issues than SSD issues, which is why I typically avoid hardware RAID in production environments unless there's a specific reason for it. RAID controllers tend to be buggy pieces of shit, usually implementing some RAID method that's more-or-less proprietary and unique even between different RAID cards from the same vendor (meaning that if your RAID controller fail…
To expand: in my 20-year experience, no small-computer RAID 5/6 controller I have had experience with has ever saved any data, ever. All failures are hard and non-recoverable. Which begs the question: why use them at all? I mirror only.
RAIDs are in place to for your guaranteed uptime in the SLA. With the current storage density RAID5/6 is probably more fragile than single disks because UREs are very likely during a rebuild. Nonetheless having a degraded array is probably better than having an offline system and it will buy you some time to migrate. Mirrors are ideal, but it is hard to justify the upfront cost.
Re: SSDs: A gift and a curse
#66Isn't running raid1/5/6 on ssds silly b/c they'll all die at the same time? And hardware raid on top of that? Why?
SSDs have a fairly consistent failure curve (exusing firmware bugs and other random events) for a given model, so they'll wear evenly in a raid setup. This means they'll all die at the same time as writes/reads are distributed fairly evenly across the disks. Given the size of today's drives, you may not complete a rebuild before losing another disk.
Has this been proven to not be true within the past few years? I don't run redundant raid on ssds. It's either raid0 or jbod.
Re: SSDs: A gift and a curse
#67Earlier quoted context omitted.
I wouldn't say that it's never going to happen based on current trends. This kind of thing tends to be quasi-cyclic. At one time, desktop computers had separate FPUs. Over time, those got integrated onto the main CPU, but then the trend switched back, with heavy calculations moving off-CPU to the GPU. The mainframe->desktop->cloud story is similar. I say "quasi"-cyclic because (e.g.) cloud isn't really the same as ma…
I'm eagerly awaiting the part of the cycle where the GPU gets folded back into the processor. I'm really not interested in writing code against mystery-meat architectures with no documented ABI...
We're already seeing that with integrated, "soldered-on" graphics cards, and with frameworks like OpenCL, and higher-level abstractions like Theano, Torch7, etc.
Re: SSDs: A gift and a curse
#68Isn't running raid1/5/6 on ssds silly b/c they'll all die at the same time? And hardware raid on top of that? Why? SSDs have a fairly consistent failure curve (exusing firmware bugs and other random events) for a given model, so they'll wear evenly in a raid setup. This means they'll all die at the same time as writes/reads are distributed fairly evenly across the disks. Given the size of today's drives, you may not…
Not necessarily. We've been running Intel SSDs in productions at Stack Exchange for 4+ years, and just recently had our first 2.5" drive die.
That said, most of the drives in this article are consumer drives. The problem with consumer drives is that they don't have capacitors. And since your writes are cached by the drive before they go to the NAND, if you lose power all of your drives will be corrupted in the exact same way at the exact same time.
If you don't care about the data, go ahead and use them. If you do pay the extra for Enterprise drives. They really aren't _that_ much more expensive these days.
Re: SSDs: A gift and a curse
#69Isn't running raid1/5/6 on ssds silly b/c they'll all die at the same time? And hardware raid on top of that? Why? SSDs have a fairly consistent failure curve (exusing firmware bugs and other random events) for a given model, so they'll wear evenly in a raid setup. This means they'll all die at the same time as writes/reads are distributed fairly evenly across the disks. Given the size of today's drives, you may not…
Not necessarily. We've been running Intel SSDs in productions at Stack Exchange for 4+ years, and just recently had our first 2.5" drive die. That said, most of the drives in this article are consumer drives. The problem with consumer drives is that they don't have capacitors. And since your writes are cached by the drive before they go to the NAND, if you lose power all of your drives will be corrupted in the exact…
Interesting. Do you have more info on what you mean by "Not necessarily?" From what I've seen during reliability studies on SSDs, they have a fairly tight failure curve. This is very dissimilar from hard disks where there's much more variance from drive to drive.
I'm genuinely interested.
Re: SSDs: A gift and a curse
#70Of course SSD firmware is buggy. You know why? Because any half-decent electrical and computer engineering team can slap a NAND flash controller and some flash chips on a PCB, take the controller's manufacturer's reference firmware implementation, tweak the dozens of knobs provided by the reference implementation (ignore FLUSH commands, change the amount of reserved sectors, disable this, enable that, etc), change th…
Not with Seagate. I have a drive waiting to be fixed because of their silly BSY bug that renders a drive inaccessible. I'll never buy their garbage again.