From: Luben Tuikov <luben_tuikov@adaptec.com>
To: Tejun Heo <htejun@gmail.com>
Cc: Jeff Garzik <jgarzik@pobox.com>,
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 15:00:31 -0400 [thread overview]
Message-ID: <43062C4F.3070505@adaptec.com> (raw)
In-Reply-To: <430570B5.60109@gmail.com>
On 08/19/05 01:40, Tejun Heo wrote:
> 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.
Ok, so everyone seems to agree on this.
> 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.
True, this is the goal. Separation between device management
and how that device got to you, is the future and should be the
a goal.
> 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.
Please don't do that. One thing everyone in the Linux community knows
is that Linux-SCSI needs fresh minds and fresh ideas. Especially from
knowlegable folks in the storage protocols and standards.
Luben
next prev parent reply other threads:[~2005-08-19 19:00 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
2005-08-19 5:54 ` Jeff Garzik
2005-08-19 19:00 ` Luben Tuikov [this message]
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
-- strict thread matches above, loose matches on Subject: below --
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=43062C4F.3070505@adaptec.com \
--to=luben_tuikov@adaptec.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=axboe@suse.de \
--cc=htejun@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.