[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

A NON-CD issue regards the recent changes to the SG code


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

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,
	b. Add a new option to the kernel to enable/disable the
	new sg restriction code. I'm sure it was added for good

Burn Alting
burn goldweb com au

Burn Alting <burn goldweb com au>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]