From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Christie Subject: Re: bugs in handling of errors for SG_IO and SCSI_IOCT L_SEND_COMMAND ioctls to block device Date: Fri, 08 Jul 2005 11:48:08 -0500 Message-ID: <42CEAE48.9050203@cs.wisc.edu> References: Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: device-mapper development List-Id: dm-devel.ids goggin, edward wrote: > On Thu, 07 Jul 2005 23:19:57 -0500 > Mike Christie 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? Was not being able to open a dm device a bug or by design? 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.