Re: -EAGAIN and -ENOMEM from ->bi_end_io, was Re: [PATCH-v2 2/2] target/iblock: Use -EAGAIN/-ENOMEM to propigate SAM BUSY/TASK_SET_FULL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2016-03-07 at 17:18 +0100, Christoph Hellwig wrote:
> On Mon, Mar 07, 2016 at 12:03:56AM -0800, Nicholas A. Bellinger wrote:
> > > On Sun, Mar 06, 2016 at 01:55:15PM -0800, Nicholas A. Bellinger wrote:
> > > > The intended use is for any make_request_fn() based driver that invokes
> > > > bio_endio() completion directly, and sets bi_error != 0 to signal
> > > > non GOOD status to target/iblock.
> > > 
> > > But -EAGAIN and -ENOMEM are not valid drivers for bio_endio,
> > 
> > Why..?
> > 
> > >  and as far as I can tell no driver every returns them.
> > 
> > Correct, it's a new capability for make_request_fn() based drivers using
> > target/iblock export.
> 
> Please only use it once drivers, filesystem and the block layer
> can deal with it.
> 
> Right now -EAGAIN and -ENOMEM are treated as an unknown error by all
> consumers of bios, so you will get a hard error and file system shutdown.
> 

Yes, the driver needs a way to determine when a bio was submitted via
target/iblock, and it's completion consumer is capable of processing a
non-zero bi_error as retryable.

> What is your driver that is going to return this, and how does it know
> it's ѕafe to do so?

I've been using this with an out-of-tree driver for a while now, but the
most obvious upstream candidate who can benefit from this is RBD.

> 
> > >  So as-is this might be well intended but either useless or broken.
> > > --
> > 
> > No, it useful for hosts that have an aggressive SCSI timeout, and it
> > works as expected with Linux/SCSI hosts that either retry on BUSY
> > status, or retry + reduce queue_depth on TASK_SET_FULL status.
> 
> I explicitly wrote "as-is".  We need a way to opt into this behavior,
> and we also somehow need to communicate the timeout.

What did you have in mind..?

>  I think allowing
> timeouts for bios is useful, but it needs a lot more work than this
> quick hack,

>From the target side, it's not a quick hack.

These initial target/iblock changes for processing non-zero bi_error +
propagating up to target-core won't change regardless of how the
underlying driver determines if a completion consumer supports retryable
bio status, or not.

> which seems to still be missing a driver to actually
> generate these errors.

I'll include the BRD patch I've been using as the first user of this
code.

--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux