T
Tom Del Rosso
Is TLER for DVR drives qualitatively different from that for RAID drives?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
R
Rod Speed
Tom said:Is TLER for DVR drives qualitatively different from that for RAID drives?
It can be. Its no big deal if the drive gives up trying to write to a
particular sector with a DVR drive, but can be wth a RAID drive.
T
Tom Del Rosso
Rod said:It can be. Its no big deal if the drive gives up trying to write to a
particular sector with a DVR drive, but can be wth a RAID drive.
The description of the feature looks similar, but they must be different
somehow.
In a DVR the time limit can be used for reads and writes. Same for RAID, or
just reads?
It's not clear to me what happens in a RAID array if there is an error that
times out (on read and write). The drive has a bad sector, so SMART can
replace it, but that was always the case.
Before this feature came along, RAID drives didn't get dropped for one bad
sector did they? Or did they if the drive spent too much time on it?
T
Tom Del Rosso
Tom said:The description of the feature looks similar, but they must be
different somehow.
That is, different somehow besides the obvious difference in reliability.
R
Rod Speed
Tom Del Rosso wrote
Yes. Its no big deal if you give up on a bad sector quickly with
Tom Del Rosso wrote
That is, different somehow besides the obvious difference in reliability.
Yes. Its no big deal if you give up on a bad sector quickly with
R
Rod Speed
Tom Del Rosso wrote
Its the writes that matter. Longer delays on reads dont really matter with RAID.
The only thing you dont want is retrying for so long that the RAID controller
decides that the drive has died and so starts doing what it does with a dead drive.
Mainly you dont want it to retry so hard that the RAID controller decides that
the drive has died and starts doing what its supposed to do with a dead drive.
Its better to just return an error condition and let the RAID controller do what is appropriate.
Not with reads. Those arent normally replaced so the user
can try as hard as they like to recover the data in the sector.
They did if they retried so hard that the RAID controller decides that the drive has died.
Yes.
Rod Speed wrote
The description of the feature looks similar, but they must be different somehow.
Yes.
In a DVR the time limit can be used for reads and writes. Same for RAID, or just reads?
Its the writes that matter. Longer delays on reads dont really matter with RAID.
The only thing you dont want is retrying for so long that the RAID controller
decides that the drive has died and so starts doing what it does with a dead drive.
It's not clear to me what happens in a RAID array if there is an error that times out (on read and write).
Mainly you dont want it to retry so hard that the RAID controller decides that
the drive has died and starts doing what its supposed to do with a dead drive.
Its better to just return an error condition and let the RAID controller do what is appropriate.
The drive has a bad sector, so SMART can replace it, but that was always the case.
Not with reads. Those arent normally replaced so the user
can try as hard as they like to recover the data in the sector.
Before this feature came along, RAID drives didn't get dropped for one bad sector did they?
They did if they retried so hard that the RAID controller decides that the drive has died.
Or did they if the drive spent too much time on it?
Yes.
G
GMAN
You dont want a DVR drive to sit there and retry forever. Its better to justIt can be. Its no big deal if the drive gives up trying to write to a
particular sector with a DVR drive, but can be wth a RAID drive.
move on.
R
Rod Speed
GMAN wrote
Thats what I meant.
You dont want a DVR drive to sit there and retry forever. Its better to just move on.
Thats what I meant.
G
GMAN
I know, just agreeing with you.GMAN wrote
move on.
Thats what I meant.
Y
Yousuf Khan
Is TLER for DVR drives qualitatively different from that for RAID drives?
Here's some info:
Should You Use TLER Drives In Your RAID NAS? - SmallNetBuilder
http://www.smallnetbuilder.com/nas/nas-features/31202-should-you-use-tler-drives-in-your-raid-nas
In general, the same requirements affect DVR drives as RAID drives, i.e.
a need to limit a drive's internal retry methodology in favour of an
external retry methodology.
Both RAID drives and DVR drives have a real-time timeout requirement,
but for different reasons. RAID drives need to get an internal retry out
of the way in order to obtain the same data through a redundant means.
DVR drives need to get an internal retry out of the way because the data
it's storing is not all that critical and it can live without it.
Yousuf Khan
R
Rod Speed
Yousuf Khan wrote
Nope. With writes particularly, with a PVR it makes much more
sense to just give up on the bad sector very quickly and just write
what needs to be written to some other good sector instead etc
so you can keep streaming whats being recorded etc.
Its more that you dont want to retry to hard so the RAID controller
decides that the drive has died and does what its supposed to do
with a drive that has died.
And in the case of writes, doesnt even have to live
without it, just write to another sector quickly.
Tom Del Rosso wrote
Here's some info:
Should You Use TLER Drives In Your RAID NAS? - SmallNetBuilder
http://www.smallnetbuilder.com/nas/nas-features/31202-should-you-use-tler-drives-in-your-raid-nas
In general, the same requirements affect DVR drives as RAID drives,
Nope.
i.e. a need to limit a drive's internal retry methodology in favour of an external retry methodology.
Nope. With writes particularly, with a PVR it makes much more
sense to just give up on the bad sector very quickly and just write
what needs to be written to some other good sector instead etc
so you can keep streaming whats being recorded etc.
Both RAID drives and DVR drives have a real-time timeout requirement,
but for different reasons. RAID drives need to get an internal retry out of the way in order to obtain the same data
through a redundant means.
Its more that you dont want to retry to hard so the RAID controller
decides that the drive has died and does what its supposed to do
with a drive that has died.
DVR drives need to get an internal retry out of the way because the data it's storing is not all that critical and it
can live without it.
And in the case of writes, doesnt even have to live
without it, just write to another sector quickly.
F
Franc Zabkar
Is TLER for DVR drives qualitatively different from that for RAID drives?
I would think that DVR drives would not need, or not use, TLER (or ERC
or CCTL, as Seagate and Samsung refer to it). AISI, a DVR would need
to be certain that any time it updated the file system structures, it
could do so without error. In such cases it would keep trying as long
as possible. OTOH, when reading or writing AV data, it would need to
drop any frame that it couldn't handle within a maximum realtime
window. To this end it would use regular AT Read/Write commands for
the former, and ATA Streaming commands for the latter.
- Franc Zabkar
Y
Yousuf Khan
Yousuf Khan wrote
Nope. With writes particularly, with a PVR it makes much more
sense to just give up on the bad sector very quickly and just write
what needs to be written to some other good sector instead etc
so you can keep streaming whats being recorded etc.
Which is still a "retry methodology", i.e. giving up on retries is also
a methodology.
Yousuf Khan
Y
Yousuf Khan
I would think that DVR drives would not need, or not use, TLER (or ERC
or CCTL, as Seagate and Samsung refer to it). AISI, a DVR would need
to be certain that any time it updated the file system structures, it
could do so without error. In such cases it would keep trying as long
as possible. OTOH, when reading or writing AV data, it would need to
drop any frame that it couldn't handle within a maximum realtime
window. To this end it would use regular AT Read/Write commands for
the former, and ATA Streaming commands for the latter.
Wouldn't the ATA Streaming commands make automatic use of TLER and
similar features? Both features are implemented by the same drive hardware.
Yousuf Khan
R
Rod Speed
Yousuf Khan wrote
But not the last bit 'in favour of an external retry methodology'.
THATS what I was commenting on.
Rod Speed wrote
Which is still a "retry methodology", i.e. giving up on retries is also a methodology.
But not the last bit 'in favour of an external retry methodology'.
THATS what I was commenting on.
Y
Yousuf Khan
Yousuf Khan wrote
But not the last bit 'in favour of an external retry methodology'.
THATS what I was commenting on.
Well, it is also an "external" retry methodology, since it's being
demanded by the DVR firmware.
R
Rod Speed
Yousuf Khan wrote
Nope, not when the DVR drive just uses a different
sector when one reports a write failure when writing.
Rod Speed wrote
Well, it is also an "external" retry methodology, since it's being demanded by the DVR firmware.
Nope, not when the DVR drive just uses a different
sector when one reports a write failure when writing.
T
Tom Del Rosso
Rod said:Yousuf Khan wrote
Nope, not when the DVR drive just uses a different
sector when one reports a write failure when writing.
When is that sector going to be relocated then? I assume the RAID drive
would give up fast but relocate it.
R
Rod Speed
When is that sector going to be relocated then?
At that time. It just does that much sooner than it otherwise
would, doesnt bother to retry much so that happens quickly.
I assume the RAID drive would give up fast but relocate it.
It doesnt have to give up fast in this case, just fast
enough so the RAID controller doesnt decide that the
whole drive has died and starts treating it as a dead drive.
F
Franc Zabkar
Wouldn't the ATA Streaming commands make automatic use of TLER and
similar features? Both features are implemented by the same drive hardware.
Good point, but I don't know the answer. I guess one way to find out
would be to retrieve the Identify Device data from a DVR drive and
examine it for ERC support.
- Franc Zabkar