From: Jeff Garzik <jgarzik@pobox.com>
To: Jens Axboe <axboe@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Silicon Image 3112A SATA trouble
Date: Sun, 30 Nov 2003 14:04:36 -0500 [thread overview]
Message-ID: <3FCA3F44.6070401@pobox.com> (raw)
In-Reply-To: <20031130182126.GE6454@suse.de>
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
next prev parent reply other threads:[~2003-11-30 19:04 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-25 13:59 Silicon Image 3112A SATA trouble Prakash K. Cheemplavam
2003-11-29 15:39 ` Prakash K. Cheemplavam
2003-11-29 16:38 ` Julien Oster
2003-11-29 16:54 ` Jeff Garzik
2003-11-29 17:07 ` Craig Bradney
2003-11-30 1:51 ` Prakash K. Cheemplavam
2003-11-29 16:56 ` Jeff Garzik
2003-11-29 17:41 ` Miquel van Smoorenburg
2003-11-29 18:39 ` Jeff Garzik
2003-11-29 20:24 ` Marcus Hartig
2003-11-30 2:00 ` Prakash K. Cheemplavam
2003-11-30 14:47 ` Bartlomiej Zolnierkiewicz
2003-11-30 15:52 ` Prakash K. Cheemplavam
2003-11-30 16:21 ` Bartlomiej Zolnierkiewicz
2003-11-30 16:25 ` Jens Axboe
2003-11-30 16:41 ` Jeff Garzik
2003-11-30 16:51 ` Jens Axboe
2003-11-30 16:58 ` Bartlomiej Zolnierkiewicz
2003-11-30 17:06 ` Jeff Garzik
2003-11-30 17:10 ` Jens Axboe
2003-11-30 17:22 ` Jeff Garzik
2003-11-30 17:31 ` Jens Axboe
2003-11-30 17:48 ` Jeff Garzik
2003-11-30 17:56 ` Vojtech Pavlik
2003-11-30 18:17 ` Jens Axboe
2003-11-30 18:19 ` Jeff Garzik
2003-11-30 18:22 ` Jens Axboe
2003-11-30 18:31 ` Jeff Garzik
2003-11-30 19:44 ` Vojtech Pavlik
2003-11-30 21:05 ` Yaroslav Klyukin
2003-11-30 17:08 ` Jens Axboe
2003-11-30 17:13 ` Bartlomiej Zolnierkiewicz
2003-11-30 17:13 ` Jens Axboe
2003-11-30 17:18 ` Jeff Garzik
2003-11-30 17:28 ` Jens Axboe
2003-11-30 17:41 ` Jeff Garzik
2003-11-30 17:45 ` Jens Axboe
2003-11-30 17:57 ` Jeff Garzik
2003-11-30 18:21 ` Jens Axboe
2003-11-30 19:04 ` Jeff Garzik [this message]
2003-11-30 19:39 ` Jens Axboe
2003-11-30 20:35 ` Jeff Garzik
2003-12-01 9:02 ` Jens Axboe
2003-11-30 17:19 ` Prakash K. Cheemplavam
2003-11-30 18:07 ` Bartlomiej Zolnierkiewicz
2003-11-30 21:34 ` Prakash K. Cheemplavam
2003-11-30 16:27 ` Jeff Garzik
2003-11-30 16:34 ` Bartlomiej Zolnierkiewicz
[not found] <Pine.LNX.4.44.0311291453550.838-100000@coffee.psychology.mcmaster.ca>
2003-11-30 16:45 ` Jeff Garzik
2003-11-30 17:52 Luis Miguel García
2003-11-30 17:13 ` Craig Bradney
2003-11-30 18:27 ` Jeff Garzik
2003-11-30 18:41 Luis Miguel García
2003-11-30 21:15 ` Craig Bradney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3FCA3F44.6070401@pobox.com \
--to=jgarzik@pobox.com \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).