From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Steven Haber <steven@qumulo.com>,
linux-scsi@vger.kernel.org, Jens Axboe <axboe@kernel.dk>
Subject: Re: SCSI eats error from flush failure during hot plug
Date: Thu, 26 Jun 2014 11:04:56 -0400 [thread overview]
Message-ID: <1403795096.3572.8.camel@dabdike> (raw)
In-Reply-To: <20140626150055.GB11199@infradead.org>
On Thu, 2014-06-26 at 08:00 -0700, Christoph Hellwig wrote:
> On Thu, Jun 26, 2014 at 10:02:47AM -0400, James Bottomley wrote:
> > Yes, but think what you're proposing. Every block command with a
> > special setup goes via scsi_setup_blk_pc_cmnd() because they usually
> > have to translate to something special.
>
> That logic is backwards. The "special" commands use
> scsi_setup_blk_pc_cmnd because that seemed the easiest we to do it
> when they were introduce. Looking back they should have just called
> scsi_init_io directly instead of doing enough setup to pretend to be
> BLOCK_PC enough to use scsi_setup_blk_pc_cmnd().
>
> > If we did what you propose,
> > every time we add one, we'd have to modify these five places in the code
> > plus the setup ... it's a bit insane plus a maintenance nightmare.
>
> It's not. They need to be treated special because they _are_ special.
If there's a problem outside the normal processing then it needs to be
solved once, not once for every new special block command type.
> If you look at the command types there's a pretty clear difference
> between BLOCK_PC and everything else:
>
> BLOCK_PC read/write discard/flush/write_same
> need to generate CDB no yes yes
> calls into the ULD no yes yes
> needs error handling no yes yes
> passes sense data up yes no no
Right, but look what we do for the specials. The only difference is the
ULD has a hook to generate the CDB. For everything else we follow the
BLOCK_PC path, including error handling and sense data processing.
> so they surely aren;t like BLOCK_PC, and treating them like BLOCK_PC
> would require major changes to our architecture. Not that I'm overly
> happy with them being _FS requests either - they probably should have
> a cmd_type assigned for each of them and come down from the block
> layer set up that way. I'll look into that once I get a little bit of
> time.
OK, we'll us this as a fix for the bug. If you come up with something
more elegant we can replace it.
James
next prev parent reply other threads:[~2014-06-26 15:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-05 23:52 SCSI eats error from flush failure during hot plug Steven Haber
2014-06-07 19:29 ` James Bottomley
2014-06-09 17:21 ` Steven Haber
2014-06-09 17:29 ` James Bottomley
2014-06-11 13:37 ` Christoph Hellwig
2014-06-19 18:05 ` James Bottomley
2014-06-25 13:13 ` Christoph Hellwig
2014-06-26 14:02 ` James Bottomley
2014-06-26 15:00 ` Christoph Hellwig
2014-06-26 15:04 ` James Bottomley [this message]
2014-06-26 15:08 ` Christoph Hellwig
2014-06-26 18:52 ` James Bottomley
2014-06-27 7:53 ` Christoph Hellwig
2014-06-26 15:02 ` Christoph Hellwig
2014-06-26 18:13 ` Steven Haber
2014-06-26 18:52 ` James Bottomley
2014-06-27 7:55 ` Christoph Hellwig
[not found] ` <CAPK7rjdpxAALA-oLZJ3wDBPc3kr5Nw4jLALLxEaT0zSiAOD+wg@mail.gmail.com>
2014-06-30 18:45 ` Steven Haber
2014-07-01 8:15 ` Christoph Hellwig
2014-07-03 16:57 ` Steven Haber
2014-07-03 17:18 ` Christoph Hellwig
2014-07-09 22:38 ` James Bottomley
2014-07-10 7:44 ` Christoph Hellwig
2014-07-17 15:27 ` Martin K. Petersen
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=1403795096.3572.8.camel@dabdike \
--to=james.bottomley@hansenpartnership.com \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=steven@qumulo.com \
/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