I would like to point out that if your drive is set as free in a RAID1 you don't lose any data, simply destroy the now degraded array and create a new one from the free drive. (when creating a raid1 array you have the option to keep the data on one of the two drives used). I have done it before.
That is true; a RAID1 is easily recoverable. But this is sort of a separate issue. Let's explain by example:
1) you have a RAID1 of two drives without TLER/CCTL/ERC for example WD EARS drives
2) one day, the second drive goes kaput as in -- permanently dead.
3) now you are left with a degraded RAID1 that is still accessible; but of course you buy a new drive and use it to rebuild the RAID1
4) however, during the rebuild, the remaining good drive encounters an unreadable sector (uBER), and it lacks TLER causing the controller to disconnect that drive from the RAID. Now you have a FAILED array because the first disk is marked 'free' or 'non-member' and the second drive did not finish rebuilding yet.
In this case, you have lost access to your data
temporarily. You can recover the data quite easily by either re-creating a RAID1 using only the first drive, or disable RAID altogether and use the primary drive as a normal drive. This is possible due to the nature of RAID1 since it has the same contents as if it was a non-RAID drive. All data is 'contiguous'; a primary benefit of RAID1.
However, the story above applies to
ease of recovery after uBER problems causing the RAID array to fail. If it were a RAID5 and uBER caused the array to be inaccessible, that also does not mean the data is permanently gone; it is just temporarily inaccessible until you recover it the proper way. The only difference here is that recovering from such a situation is much easier with a RAID1 than it is recovering a RAID5. Also, user errors can cause such recovery to permanently overwrite and thus destroy your data for a RAID5; which depends on disk order and parity data to retrieve your data.
So while a RAID1 has distinct advantages causing recovery in the event of 'problems with the RAID layer' it is not impervious to uBER problems. I do agree however that RAID1 for many people would be a much safer choice than RAID5. But each RAID level has its own advantages. For a large 40 drive build using RAID1 is a gigantic waste of storage space.
Also i'm not sure whether RAID1 for home users is such a good idea. Many people consider it to be a backup, while in fact it only protects against physical harddrive failures. It does not protect against accidental deletion, filesystem corruption, virusses of common causes like fire, lightning or a bad power supply causing multiple if not all drives in a system to die simultaneously.
The best setup is one which focuses on having a reliable backup. For most users a good setup would be to use a backup drive in another computer on the local network; such as a bedroom PC. Assume that PC is off most of the time but only on at some hours at which an automatic incremental backup takes place, then this would be a cheap but very reliable means of backup; since the backup shares as little risk with the primary data. Only disasters like flood, fire and excessive lightning would be able to kill your data. A risk that for most people is acceptable.
sub.mesa: I'm confused as to what your bottom line is for using WD drives, specifically in a unit like the UltraNAS. Are you actually saying they are less prone to catastrophic failure because of TLER? Sorry I'm a bit slow...
TLER or CCTL or ERC does not affect the reliability of the drive; whether it fails or not. It only affects the behavior of the drive when it encounters a bad sector; that is a piece of data that is unreadable. Normal drives without said functionality continue trying to read that data. This causes hardware RAID and Windows-specific software RAIDs to consider the entire drive as failed because it is not responding in time to the controller.
To remedy this problem, TLER is useful since it causes the drive to stop trying to recover, and leave it up to the controller on how to continue in such an event. This will solve the problem of disks that get 'kicked out' of the RAID array, an issue that frequently causes haywire on consumer RAID systems.
You either need TLER, or you don't. If you do not need TLER, then you do not want it, since it can be dangerous as well. You need TLER if your controller is strict about drive timeouts; this depends on the controller. I cannot say whether the UltraNAS expects TLER-enabled drives. You could ask your supplier whether that is the case. If it accepts normal consumer drives then you do not have to use TLER.
As in the case of ZFS, you do not need nor want TLER functionality. TLER is dangerous is the case where there is no redundant copy available on another disk in the RAID array and as such the disks recovery abilities are the only chance left to access that part of data. With a TLER drive stopping any recovery attempt in 7 seconds, chances are that you cannot read a sector which would have been readable with TLER functionality disabled.
Some people regard TLER and the likes (CCTL/ERC) as a 'dirty bugfix' to controllers which cannot tell the difference whether a drive is not responding because it has failed, or a drive that is not responding because it is performing recovery and the controller should just wait or let the drive know the data is not needed anymore by writing to the same sector. ZFS is quite smart and will write to drives that have an unreadable sector; this is the best behavior possible since it solves all problems; the unreadable sector on the drive and the problem of drives being kicked out of the array.
Hope this solves your confusion; if not please ask and I'll try to be more clear.
Facebook
Twitter