James Bottomley wrote: > On Wed, 2006-05-10 at 12:41 -0400, Douglas Gilbert wrote: > >>Looks good. There is no proposed change to sg.c . >>Could SG_FLAG_FAILFAST be made to work via sg device >>nodes? > > > Rather than having to maintain two separate paths for SG_IO and hence > keep running into this issue, what will it take for sg to use the block > scsi_ioctl.c? Methinks a large amount of code and a lot of testing. Hannes is proposing a new SG_FLAG value that would only be active in the block layer SG_IO. The existing SG_FLAG values are only implemented by the sg driver. Around that level in the sg driver, the command injection and response processing are asynchronous and that can be exposed to the sg user. The block SG_IO is synchronous with no easy way to break it down to its component parts. On further thought if anything in the scsi midlayer (or the block layer) is slowing down an error report getting back to a sg user then that is most likely a bug. The sg driver sends commands with retries set to zero. Also settings in the read/write error recovery mode page can effect how long a disk (or cd/drive) spends trying to recovery from errors (and SG_FLAG_FASTFAIL has no effect at the device (lu) end). Doug Gilbert - : 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
