Yousuf Khan wrote
> Tom Del Rosso wrote

>> 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/n...-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.

On Wed, 14 Mar 2012 19:58:09 -0400, "Tom Del Rosso"
<(E-Mail Removed)> put finger to keyboard and composed:

>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
--
Please remove one 'i' from my address when replying by email.

On 16/03/2012 2:23 AM, Rod Speed wrote:
> Yousuf Khan wrote
>> 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.

Which is still a "retry methodology", i.e. giving up on retries is also
a methodology.

Yousuf Khan

On 16/03/2012 3:08 AM, Franc Zabkar wrote:
> On Wed, 14 Mar 2012 19:58:09 -0400, "Tom Del Rosso"
> <(E-Mail Removed)> put finger to keyboard and composed:
>
>> 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.

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

Yousuf Khan wrote
> Rod Speed wrote
>> Yousuf Khan wrote

>>> 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.

> 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.

On 16/03/2012 7:03 PM, Rod Speed wrote:
> Yousuf Khan wrote
>> 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.

Well, it is also an "external" retry methodology, since it's being
demanded by the DVR firmware.

Yousuf Khan wrote
> Rod Speed wrote
>> Yousuf Khan wrote
>>> 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.

> 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.

Rod Speed wrote:
> Yousuf Khan wrote
> > Rod Speed wrote
> > > Yousuf Khan wrote
> > > > 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.
>
> > 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.

When is that sector going to be relocated then? I assume the RAID drive
would give up fast but relocate it.


--

Reply in group, but if emailing add one more
zero, and remove the last word.

Tom Del Rosso wrote:
> Rod Speed wrote:
>> Yousuf Khan wrote
>>> Rod Speed wrote
>>>> Yousuf Khan wrote
>>>>> 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.

>>> 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.

> 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.

On Fri, 16 Mar 2012 09:39:55 -0400, Yousuf Khan
<(E-Mail Removed)> put finger to keyboard and composed:

>On 16/03/2012 3:08 AM, Franc Zabkar wrote:
>> On Wed, 14 Mar 2012 19:58:09 -0400, "Tom Del Rosso"
>> <(E-Mail Removed)> put finger to keyboard and composed:
>>
>>> 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.
>
>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
--
Please remove one 'i' from my address when replying by email.