From: Tejun Heo <htejun@gmail.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-kernel@vger.kernel.org, Jens Axboe <axboe@suse.de>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: libata error handling
Date: Fri, 19 Aug 2005 14:40:05 +0900 [thread overview]
Message-ID: <430570B5.60109@gmail.com> (raw)
In-Reply-To: <430556BF.5070004@pobox.com>
Hi, Jeff.
Jeff Garzik wrote:
>
> Tejun,
>
> In an email I cannot find anymore, you asked why I was interested in
> converting libata to use the fine-grained EH hooks in the SCSI layer,
> rather than continued with the current ->eh_strategy_handler() method.
>
> Several reasons:
>
> 1) The fine-grained hooks of the SCSI layer are somewhat standard for
> block devices. The events they signify -- timeout, abort cmd, dev
> reset, bus reset, and host reset -- map precisely to the events that we
> must deal with at the ATA level.
I genearally agree that the events are somewhat standard for block
devices but IMHO SCSI EH also has fair amount SCSI-specific assumptions
and ATA is a bit too different from SCSI to fit cleanly into it. For
example, when handling NCQ errors, the whole task set is aborted and the
status is retrieved with read log page. This can be worked around in
one of the hooks and emulate SCSI behavior, but it just doesn't really
fit well. And I think that recovering via translation layer is a bit
too much translation.
So, my thought is that SCSI EH assumptions are a bit too specific to
be used as standard for block devices.
> But be warned of false sharing, as I talk about in #2...
>
> 2) When libata SAT translation layer becomes optional, and libata drives
> a "true" block device, use of ->eh_strategy_handler() will actually be
> an obstacle due to false sharing of code paths. ->eh_strategy_handler()
> is indeed a single "do it all" EH entrypoint, but within that entrypoint
> you must perform several SCSI-specific tasks.
It's true that we must do SCSI specific tasks inside libata if we use
eh_strategy_handler but I don't think switching to fine-grained EH will
reduce the amount of SCSI-specific things inside libata. I think as
long as we can insulate LLDD's from SCSI layer, either way should be
okay later.
>
> 3) ->eh_strategy_handler() has continually proven to be a method of
> error handling poorly supported by the SCSI layer. There are many
> assumption coded into the SCSI layer that this is -not- the path taken
> by LLD EH code, and libata must constantly work around these assumptions.
>
> 4) libata is the -only- user of ->eh_strategy_handler(), and oddballs
> must be stomped out. It creates a maintenance burden on the SCSI layer
> that should be eliminated.
I agree that being the only user does incur difficulties, but my very
subjective feeling is that the original libata EH implementation was
just a bit too fragile to start with. eg. not grabbing host lock on EH
entrance causing command completion vs. EH handling race and handling
errors in several different ways.
Heh... Maybe I'm just reluctant to let go of my patches. Anyways,
I'll now stand down and see how things go and try to help.
Thanks, always.
--
tejun
next prev parent reply other threads:[~2005-08-19 5:40 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-29 5:06 [RFC][PATCH] libata ATAPI alignment Jeff Garzik
2005-07-29 13:38 ` Alan Cox
2005-08-02 8:27 ` Jens Axboe
2005-08-02 14:31 ` Jeff Garzik
2005-08-07 5:48 ` Tejun Heo
2005-08-07 5:53 ` [PATCH 1/2] sata: fix sata_sx4 dma_prep to not use sg->length Tejun Heo
2005-08-10 21:24 ` Jeff Garzik
2005-08-07 5:58 ` Rd: [PATCH 2/2] sata: implement ATAPI alignment adjustment Tejun Heo
2005-08-07 6:17 ` [PATCH 3] sata: restore sg on setup failure Tejun Heo
2005-08-19 3:49 ` libata error handling Jeff Garzik
2005-08-19 5:40 ` Tejun Heo [this message]
2005-08-19 5:54 ` Jeff Garzik
2005-08-19 19:00 ` Luben Tuikov
2005-08-19 18:46 ` Luben Tuikov
2005-08-19 19:38 ` Patrick Mansfield
2005-08-19 20:03 ` Luben Tuikov
2005-08-19 20:11 ` Patrick Mansfield
2005-08-19 20:43 ` Luben Tuikov
2005-08-19 21:10 ` Patrick Mansfield
2005-08-19 22:37 ` Luben Tuikov
2005-08-19 20:29 ` Mike Anderson
2005-08-19 21:02 ` Luben Tuikov
2007-01-06 14:26 Kasper Sandberg
[not found] <fa.pdj7pJD9C08bRZatFINV1hz1oyA@ifi.uio.no>
2007-01-06 18:21 ` Robert Hancock
2007-01-06 18:57 ` Kasper Sandberg
2007-01-06 19:01 ` Robert Hancock
2007-01-06 19:08 ` Kasper Sandberg
2007-01-06 19:28 ` Bartlomiej Zolnierkiewicz
2007-01-07 20:07 ` Kasper Sandberg
2007-01-07 20:38 ` Bartlomiej Zolnierkiewicz
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=430570B5.60109@gmail.com \
--to=htejun@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=axboe@suse.de \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@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).