Prev: dimension of ibm server x-series?
Next: Suggestions Please...
From: Arno Wagner on 24 Apr 2008 02:42
Previously Franc Zabkar <fzabkar(a)iinternode.on.net> wrote:
> On 17 Apr 2008 20:56:34 GMT, Arno Wagner <me(a)privacy.net> put finger
> to keyboard and composed:

>>Seek errors are due to modern drives
>>starting reading before the heads have settled. This usually works,
>>but when it does not work it becomes a seek error.

> I've been searching for references to support your statement but I
> haven't had any luck. I know from personal experience that older
> drives could be commanded to seek with a positive or negative track
> offset. Positioning the head slightly off-track and attempting a read
> was commonly done during low level formatting to test the integrity of
> the data surface. Any track that failed would be taken out of service
> and replaced with a spare. Servo offsets could also be used when
> recovering data from marginal sectors.

Actually I do not have a good reference myself. It is something
that accumulated when looking into modern HDD technology and
the possibilities of recovering overwritten data. Supporting
data is that for some intermediate HDD generations reads
were faster than writes by a notable margin. I do not remember
exactly whether I found an explicit statement about this behaviour,
or whether it is my conclusion from accumulayed facts. So, strictly
speaking, this may only be a hypothesis, but is is a good one.

> I notice that some Seagate product manuals specify a lower number for
> average seek time during reads as opposed to writes (8.5ms versus
> 10ms). Track-to-track seeks are also lower (0.8ms versus 1.0ms).

Ah, so this is still going on.

> I don't know whether this reflects the operation of the drive's read
> ahead cache or whether it supports your claim regarding a "preemptive"
> read strategy.

Caches/buffers are not involved here. Otherwise they would
certainly also include them for writing, and write-buffers
can hav a lot more impact than read-ahead.

Arno
From: Franc Zabkar on 24 Apr 2008 05:46
On 24 Apr 2008 06:42:53 GMT, Arno Wagner <me(a)privacy.net> put finger
to keyboard and composed:

>Previously Franc Zabkar <fzabkar(a)iinternode.on.net> wrote:

>> I notice that some Seagate product manuals specify a lower number for
>> average seek time during reads as opposed to writes (8.5ms versus
>> 10ms). Track-to-track seeks are also lower (0.8ms versus 1.0ms).
>
>Ah, so this is still going on.
>
>> I don't know whether this reflects the operation of the drive's read
>> ahead cache or whether it supports your claim regarding a "preemptive"
>> read strategy.
>
>Caches/buffers are not involved here. Otherwise they would
>certainly also include them for writing, and write-buffers
>can hav a lot more impact than read-ahead.
>
>Arno

Yes, that makes sense. It seems, then, that your preemptive read
hypothesis is plausible.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.
From: Folkert Rienstra on 24 Apr 2008 07:42
Franc Zabkar wrote in news:0il0141ha4hojccg9r0sj6lvsujtget8vo(a)4ax.com
> On 24 Apr 2008 06:42:53 GMT, Arno Wagner <me(a)privacy.net> put finger
> to keyboard and composed:
>
> > Previously Franc Zabkar <fzabkar(a)iinternode.on.net> wrote:
>
> > > I notice that some Seagate product manuals specify a lower number for
> > > average seek time during reads as opposed to writes (8.5ms versus
> > > 10ms). Track-to-track seeks are also lower (0.8ms versus 1.0ms).
> >
> > Ah, so this is still going on.
> >
> > > I don't know whether this reflects the operation of the drive's read
> > > ahead cache or whether it supports your claim regarding a "preemptive"
> > > read strategy.
> >
> > Caches/buffers are not involved here. Otherwise they would
> > certainly also include them for writing, and write-buffers
> > can hav a lot more impact than read-ahead.
> >
> > Arno
>
> Yes, that makes sense.

> It seems, then, that your preemptive read hypothesis is plausible.

Yes it is, just not what he thinks it is. And it's your naming, not his.

>
> - Franc Zabkar
From: Folkert Rienstra on 22 Apr 2008 18:43
Franc Zabkar wrote in news:jq6v04pghj6ilcu188g2enl14opavt48j0(a)4ax.com
> On 17 Apr 2008 20:56:34 GMT, Arno Wagner <me(a)privacy.net> put finger
> to keyboard and composed:
>
> > Seek errors are due to modern drives starting reading before the
> > heads have settled. This usually works, but when it does not work it
> > becomes a seek error.

> I've been searching for references to support your statement but I
> haven't had any luck.

Gee, there's a big surprise.

> I know from personal experience

Personal experience, no less.

> that older drives could be commanded to seek with a positive or negative
> track offset.
> Positioning the head slightly off-track and attempting a read was commonly
> done during low level formatting to test the integrity of the data surface.

Right, and it was you 'personally' that held the heads off track.

> Any track that failed would be taken out of service
> and replaced with a spare. Servo offsets could also be used when
> recovering data from marginal sectors.
>
> I notice that some Seagate product manuals specify a lower number
> for average seek time during reads as opposed to writes (8.5ms ver-
> sus 10ms). Track-to-track seeks are also lower (0.8ms versus 1.0ms).

One reason could be that this is an average and the increase of the ave-
rage is caused by just some writes having to wait another full rev due to
the servo system deciding it's not certain that it is on the correct track
due to the sector being near but not enough track marks on the track,
to have read (just) one, before the sector arrives.
On a read the drive can read the sector and confirm the track number
afterwards and let it go through (or not) depending on the outcome. On
a write that's not possible as that's destructive and it doesn't want the
wrong sector overwritten so it lets the opportunity pass and do another rev.

Nothing to do with the heads "having settled" and poor
reads that make or don't make it through error correction.

> I don't know whether this reflects the operation of the drive's read
> ahead cache or whether it supports your claim regarding a

> "preemptive" read strategy.

Close, but that's not what he said.

>
> - Franc Zabkar
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: dimension of ibm server x-series?
Next: Suggestions Please...