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. What is your driver that is going to return this, and how does it know it's ѕafe to do so? > > 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. I think allowing timeouts for bios is useful, but it needs a lot more work than this quick hack, which seems to still be missing a driver to actually generate these errors. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
