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-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
