"Søren Schmidt" wrote:
> It seems Terry Lambert wrote:
> > "Søren Schmidt" wrote:
> > > > Is your drive perchance an IBM DTLA?
> > > >
> > > > It's known to have these problems.
> > >
> > > Cool! would you like to share where that information is available so
> > > I can possibly work around the problem ??
> > IBM DTLA drives are known to be problematic. If you use that
> > in a search engine, it will find numerous references to the
> > drive electronics being too slow for sustained access to the
> > sectors closes to the spindle.
> This thread is about tagged queueing problems on IBM drives since they
> are the only ones that supports it, it is not specific to the DTLA
> series at all, which this thread has already explained.
> So Terry, do you have anything to share, or just noise like this ?
> (I dont care about if the DTLA may have other problems)
Sorry; all I can give you is hear-say, which I guess you could
consider to be noise, except we confirmed that the problem disk
in this case was an IBM drive, which tends to support the theory.
On the Linux kernel list, they suggested that the electronics
that were too slow near the spindle were too slow at the rim, too,
if you used tagged command queueing to increase the host load on
the drive to the point that it was always dealing with back-to-back
transfers. In other words, you *would* overwhelm the drive at the
spindle, and you *could* overwhelm it at the rim, if you did it right,
according to the posters.
Basically, all I'm doing is repeating some arguments I saw elsewhere,
not my personal experience with the beasts.
My own personal experience with DTLA drive problems is limited to seeing
some data corruption problems, reading the Linux lists, and then
repartitioning the disks to not use the area near the spindle, which
seemed to fix the problem to the point I could ignore investigating it
further, and switch vendors when the in-stock DTLA's ran out.
From a strictly "scientific proof" point of view, I might as well have
waved a dead chicken over the things, and attributed the non-observation
of problems afterward to that. On the other hand, "anything that works
is better than anything that doesn't work"... 8-) 8-).
For a more "scientific test", downloading the firmware tool and
setting the DMA transfer rate down, and checking for problems,
would be pretty overwhelming evidence. Personally, I don't have
any of the buggers lying around to test with any more.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message