Hi, I regularly use and author tools like Doug Gilbert's sg_dd on disk drives and raids hanging off both parallel scsi and fibre channel HBA's. The problem I've found with the decision to not allow sg access to any device already 'claimed' by another driver is that I can't perform large IO's to the devices and hence test their sustained sequential throughput. Lets take the simple case of performing a single 1MB read off a raid attached via an LSI Logic FC HBA. This is under 2.6.5-1.358smp sg_dd if=/dev/sda of=/dev/null bs=512 bpt=2048 count=2048 blk_sgio=1 sg_read failed, try reducing bpt, seek=0 Some error occurred, remaining block count=2048 0+0 records in 0+0 records out Hmmm ... I can't I have to drop down to a 256 block transfer size before the driver accepts it and passes it through to the device. If I use a 2.6.6 generic kernel, I have access to the scsi generic device so the 1MB transfer works with /dev/sg0 although the limitation of a max 256 block transfer is still in the /dev/sda driver. My suggestion is either a. Remove the new sg restriction code and keep consistent with the generic Linux kernel, or b. Add a new option to the kernel to enable/disable the new sg restriction code. I'm sure it was added for good reason. Regards Burn Alting burn@xxxxxxxxxxxxxx -- Burn Alting <burn@xxxxxxxxxxxxxx>
