|
|
This topic comprises 2 pages: 1 2
|
|
Author
|
Topic: GDC SX3000 - movie freezing randomly
|
Marcel Birgelen
Film God
Posts: 3357
From: Maastricht, Limburg, Netherlands
Registered: Feb 2012
|
posted 11-07-2018 03:21 AM
quote: Steve Guttag
Note, I distinction between Enterprise drives and desktop/laptop drives is that an Enterprise drive should NOT re-read a bad area, it should mark the sector bad and move on since the other drives in the RAID have the data.
Unfortunately, it's not entirely consistent across the line. At least not with the multitude of different types of disks I've seen go through across the years.
The biggest difference between "Enterprise" and "Desktop" drives is that Enterprise firmware ensures you the drive will not go to sleep after a certain period of idle time. Those sleep modes are obviously killing for RAID. That's why you most definitely want to avoid Desktop disks for any RAID solution.
But nowadays, there are many different types of drives, even across SATA drives, targeted at different applications. But most of those distinctions are pretty much bollocks, they make no noticeable difference. For example, I haven't really seen any improvement using "highest end" disks targeted at stuff like camera surveillance, compared to "vanilla" enterprise disks. Their failure modes seem to be identical and they also tend to slow an entire array down if they start to fail intermittently.
I've also tested disks that claimed to be "RAID optimized", but I've also seen the typical failure modes on those disks, where an intermittent failure leads to abysmal RAID performance.
(The biggest troubles I've had with this were actually on RAID arrays using SSDs, since SSDs are not so easy to debug and not always seem to log their internal struggles...)
The re-read instructions in SATA that are blocking are mostly initiated by the controller. A simple, recoverable error usually doesn't induce so much latency it really blocks the RAID array operation. The disk will silently relocate the bad block to another spare block. Most disks also have sufficient cache to do so during some idle loops.
Most enterprise systems don't run RAID-5 anymore. It's at the very least a double-parity system like RAID-6 or often a combination, like RAID-60 or a vendor specific RAID-like solution. Those kind of configurations give a lot more redundancy, but also require a bigger overhead and large disk count.
The biggest difference although, is inside the controllers. Those controllers are specifically built for those tasks and are highly expensive.
Modern storage manufacturers like EMC, NetApp, etc. allow you to configure an array for a specific task. Those controllers constantly monitor the throughput of the disks. Also, most of them are backed with a significant amount of non-volatile memory used as write buffer, which can be used as a buffer, if the performance of a disk suddenly drops. Within the time of this buffer, the array can decide whether or not to eject a disk from the array, without creating an impact on the applications atop of the array. Also, if you're running a double-parity or even triple-parity system, the potential impact on the availability and consistency of the data on the array is way less if you eject a single disk, than compared to a RAID-5 array, where after the second disk dies, you're in for a likely disaster.
Those enterprise systems also tend to employ stronger hardware than average RAID controllers, so that a missing disk, where missing data needs to be reconstructed from checksums doesn't lead to any noticeable impact. Many of those systems also don't wait for retries from the disk, instead they automatically start to reconstruct the data for the requested block and return this, if one of the disks starts to lag behind.
| IP: Logged
|
|
|
|
|
|
|
|
|
|
Marcel Birgelen
Film God
Posts: 3357
From: Maastricht, Limburg, Netherlands
Registered: Feb 2012
|
posted 11-08-2018 08:11 AM
quote: Mark Gulbrandsen
Ahhh hummmm.... You can indeed lose two drives from a PDP-3000 raid as long as it is allowed to rebuild each time you remove a drive.
Well, to me it's also not entirely clear what you're saying here.
You can go through a degraded -> rebuild -> healthy -> degraded ... cycle as many times as you want, as long as you only lose one disk at a time.
If you lose a second disk in a RAID 5, what you can try with some controllers is to force the array on-line. Normally, the RAID controller will immediately stop all I/O to and from the array as soon as the second disk in your RAID-5 array gets ejected.
Not all controllers do have the option, but forcing the array on-line can give you a last resort of evacuating some remaining data from the array, as long as the last disk being ejected isn't completely dead. The problem though, is that as soon as you hit one of those sectors that got the disk ejected the last time, you will most likely see your array drop off-line again. I have recovered some essential data from some failed arrays this way.
The only other way to recover (parts) of your data otherwise from a failed array is sending your disks to a company specialized in reading the data directly from the platters with very specialized equipment. Those services can cost multiple tens of thousands of dollars, depending on the amount of data to be recovered.
| IP: Logged
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
All times are Central (GMT -6:00)
|
This topic comprises 2 pages: 1 2
|
Powered by Infopop Corporation
UBB.classicTM
6.3.1.2
The Film-Tech Forums are designed for various members related to the cinema industry to express their opinions, viewpoints and testimonials on various products, services and events based upon speculation, personal knowledge and factual information through use, therefore all views represented here allow no liability upon the publishers of this web site and the owners of said views assume no liability for any ill will resulting from these postings. The posts made here are for educational as well as entertainment purposes and as such anyone viewing this portion of the website must accept these views as statements of the author of that opinion
and agrees to release the authors from any and all liability.
|
Home
Printer-friendly view of this topic