On Fri, 08 Jul 2005 11:48:08 -0500 Mike Christie <michaelc@xxxxxxxxxxx> wrote > Subject: Re: [dm-devel] bugs in handling of errors for SG_IO and > SCSI_IOCT L_SEND_COMMAND ioctls to block device > To: device-mapper development <dm-devel@xxxxxxxxxx> > Message-ID: <42CEAE48.9050203@xxxxxxxxxxx> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > goggin, edward wrote: > > On Thu, 07 Jul 2005 23:19:57 -0500 > > Mike Christie <michaelc@xxxxxxxxxxx> wrote > > > > > >>>... > >>> > >>> The bio handling for these REQ_BLOCK_PC requests shouldn't be > >>>treated any > >>> differently than the more typical REQ_CMD type block io request. > >> > > > >>what is meant by this last comment specifically? > > > > > > Just trying to make a case that a device pass through read command > > issued to a block device should transfer to user space only the > > user requested number of bytes minus the residual from the transfer > > (as is done for block device read and write requests) and not always > > transfer the number of bytes requested by the user. > > > > ah ok, I thought it was referring to something else, nevermind. > > Was the reason it does SG_IO reads becuase opens on the > device were not > allowed? Sorry, I should not have singled out pass through read commands. My statement above should have simply referred to "pass through commands which are transferring data from the device". > Was not being able to open a dm device a bug or by > design? I didn't provide my context for why the pass through commands are issued. These are test path ios initiated by the multipathd in user space -- either tur, read of sector 0, or a page 0xc0 inquiry. > For devices that do not support SG_IO like NBD, dasd and if you do > dm-multipath with AOE, another solution may have to be found. > Good point. While dm-multipath is designed to be block device protocol agnostic, its current implementation only supports SCSI devices.