• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

TLER Issue: Does it Affect RAID 0?

If you are using software RAID, not mobo/FakeRAID, then you will be totally fine.
Where TLER is really needed is for FakeRAID and hardware RAID controllers.

Computurd is right, TLER is supported on Velociraptors.
 
@OP

1) Software RAID is where the RAID engine is part of the OS, not in the firmware of a disk controller.

2) You don't want TLER in a RAID 0 array so don't worry about it.
 
Gotta throw this in there, but this isn't for your main drive is it? Because RAID0 (which isn't even technically a RAID level by definition) is a bad idea unless it's for scratch data. Make sure you are doing daily backups and/or images of the drive.

..and yes, TLER (and similar technologies) only matter when you are using a hardware RAID controller.
 
I thought software RAID was fake RAID. It's motherboard RAID; P67.

And I thought the issue was that TLER was 'supported', but malfunctioning.

Motherboard RAID aka FakeRAID aka firmware RAID is not software RAID.
 
..and yes, TLER (and similar technologies) only matter when you are using a hardware RAID controller.

Gonna add to this what I forgot to add before in my own post. The reason why you don't want TLER in RAID 0 is this:

TLER is designed so that if a drive in a RAID array hits a bad sector, instead of keep trying to read the sector (which can take up to 60 seconds), the drive gives up after 7 seconds and tells the RAID controller to handle the error. If it doesn't give up and respond to the controller quickly enough, the controller thinks that the drive is dead, and drops it from the array.

The controller then finds a redundant copy of that sector data from another drive in the array (with RAID levels 1, 0+1 or 10) or calculates the missing data from parity information (RAID levels 4, 5 and 6).

The problem with TLER in RAID 0 is that there is no redundant copy of the data anywhere, nor can it be calculated from parity because there is no parity. You NEED the drive to keep trying to recover the data from a bad sector, because good or bad, it's the only copy you have.

Hence, TLER in RAID 0 is bad.

If I'm not mistaken, Velociraptors are considered to be enterprise class drives, hence they support TLER. You may wish to ensure that TLER is set to around 60 seconds (or switched off), if you're going to use them in RAID 0.
 
Velociraptors are enterprise-grade, but are low-end-server class drives (not quite nearline class).
Yes, they do support TLER.
 
It doesnt matter because TLER has no effect on RAID0 arrays.
 
The controller then finds a redundant copy of that sector data from another drive in the array (with RAID levels 1, 0+1 or 10)
AFAIK RAID1 isn't effected because both discs are written at the same time and considered a non-parity array?
 
I would be surprised if the raid controller wrote to both sides at the same time, as that introduces a single point of failure, no?
 
I would be surprised if the raid controller wrote to both sides at the same time, as that introduces a single point of failure, no?
Would it matter?

You're writing to many drives at at time when using other types of RAID AND using the same controller to process the other parity computations.

How 'bout that for a single point of failure?
 
No argument there. That is (in a nutshell) the raid5 write hole. One reason I don't run raid5. OTOH, zfs won't have this problem...
 
ZFS is limited to specific OSes, hardware RAID is not.
Just depends on what the user needs for the situation.
 
I had a TLER issue with a couple 300 GB Velociraptors in Raid 0 with nVidia controller not liking it much pushing out parity errors. Turning off TLER gave me 6 months of piece though eventually the errors came back. WD tech support said that those 'Consumer' drives weren't rated for raid operation and not supported by warranty in raid operation. Never the less they all most worked fine in another Intel chipset system until one of the drives died. So I don't think you will have any TLER issues to worry about unless they ship you a bad drive and that could be tricky to diagnose. Lucky for me WD approved the RMA and sent me a double RMA by accident and allowed me to keep the extra drives they sent me!
 
AFAIK RAID1 isn't effected because both discs are written at the same time and considered a non-parity array?

If you're using a mirrored array, and one of the drives hits a bad sector, what happens? Will it not keep trying to read (or write) to that sector unless TLER is active?

I would be surprised if the raid controller wrote to both sides at the same time, as that introduces a single point of failure, no?

How else would you expect a mirrored array to work? Imagine copying a 1TB file to a mirrored array. Would you really want to wait for one disk to finish before you wrote a redundant copy to each of the other array members?
 
Last edited:
I'm not a disk expert, but given that most of the delay is seeking, I don't see why waiting for a write to complete before starting the second one would be that bad. Then again, that's probably not very realistic... Thinking back, in almost any real world application, what I wrote is not very realistic. I have seen a fault tolerant system where not only did it work this way, but the write was not considered complete until a read verify had been done. Keep in mind, the customers were banks, brokerage market makers, etc, for who every possible 9 was desirable, even if performance was not so good.
 
Back
Top