lkml.org 
[lkml]   [2003]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Silicon Image 3112A SATA trouble
Jens Axboe wrote:
> On Sun, Nov 30 2003, Jeff Garzik wrote:
>>Current non-errata case: 1 taskfile, 1 completion func call
>>Upcoming errata solution: 2 taskfiles, 1 completion func call
>>Your errata suggestion seems to be: 2 taskfiles, 2 completion func calls
>>
>>That's obviously more work and more code for the errata case.
>
>
> I don't see why, it's exactly 2 x non-errata case.

Since the hardware request API is (and must be) completely decoupled
from struct request API, I can achieve 1.5 x non-errata case.


>>And for the non-errata case, partial completions don't make any sense at
>>all.
>
>
> Of course, you would always complete these fully. But having partial
> completions at the lowest layer gives it to you for free. non-errata
> case uses the exact same path, it just happens to complete 100% of the
> request all the time.

[editor's note: I wonder if I've broken a grammar rule using so many
"non"s in a single email]

If I completely ignore partial completions on the normal [non-error]
paths, the current errata and non-errata struct request completion paths
would be exactly the same. Only the error path would differ. The
lowest [hardware req API] layer's request granularity is a single
taskfile, so it will never know about partial completions.



>>>>WRT error handling, according to ATA specs I can look at the error
>>>>information to determine how much of the request, if any, completed
>>>>successfully. (dunno if this is also doable on ATAPI) That's why
>>>>partial completions in the error path make sense to me.
>>>
>>>
>>>... so if you do partial completions in the normal paths (or rather
>>>allow them), error handling will be simpler. And we all know where the
>>
>>In the common non-errata case, there is never a partial completion.
>
>
> Right. But as you mention, error handling is a partial completion by
> nature (almost always).

Agreed. Just in case I transposed a word or something, I wish to
clarify: both errata and error paths are almost always partial completions.

However... for the case where both errata taskfiles completely
_successfully_, it is better have only 1 completion on the hot path (the
"1.5 x" mentioned above). Particularly considering that errata
taskfiles are contiguous, and the second taskfile will completely fairly
quickly after the first...

The slow, error path is a whole different matter. Ignoring partial
completions in the normal path keeps the error path simple, for errata
and non-errata cases. Handling partial completions in the error code,
for both errata and non-errata cases, is definitely something I want to
do in the future.


>>>hard and stupid bugs are - the basically never tested error handling.
>>
>>I have :) libata error handling is stupid and simple, but it's also
>>solid and easy to verify. Yet another path to be honed, of course :)
>
>
> That's good :). But even given that, error handling is usually the less
> tested path (by far). I do commend your 'keep it simple', I think that's
> key there.

As a tangent, I'm hoping to convince some drive manufacturers (under NDA
most likely, unfortunately) to provide special drive firmwares that will
simulate read and write errors. i.e. fault injection.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.170 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site