On Wed, 2010-12-22 at 14:54 +0100, Hannes Reinecke wrote: > Well, sort of. 'sg' doesn't have any block queue limits directly as the > block queue is attached to the block device (surprise, surprise :-). > But nevertheless any commands send via SG_IO are being placed on the > block queue, hence the same limits apply here, too.
Right, tho is there a "simple" way to map sg to the appropriate block driver to retreive the info via sysfs ? I looks possible from a quick peek there but it also looks like an ungodly mess. > If it were me I would be using I think you meant to type more here :-) > > However, I can't quite figure out how to reliably obtain that > > information in my driver since on one hand, the ioctl doesn't seem to > > work in mixed 32/64-bit environments, and on the other hand, sysfs > > doesn't seem to have anything for "sg" in /sys/class/block... Besides, > > those are both Linux-isms... so we'd have to be extra careful there too. > > > Yes. I've been bashing my head against this, too. Christoph, any suggestion there ? > IMO the whole problem arises from the fact that we're deliberately > destroying information here. > Most modern HBAs are using separate codepaths for streaming/block I/O > anyway, but when using 'scsi-generic' we are forced to discard this > information. We have to fake a SCSI READ/WRITE command, and send it via > SG_IO to the underlying device and keep fingers crossed that we're not > exceeding any device limitations. I wouldn't say it like that no. It's a transport problem. In my case I'm not "faking" anything, vscsi is just a transport (a variant of SRP). The problem is that when 'emulating' a HW HBA, you have no way to express the intrinsic limitations of the underlying HBA, but that's not a problem I have with vscsi which is meant to be a transport and as such does have means to convey that sort of information (tho in my case, I have some issues due to assumptions/bugs in the existing ibm vscsi client driver but that's a different topic). So I think there's a significant difference here between emulating a HW HBA and doing something like vscsi. The former has problems that cannot be easily solved I believe. The later problems on the other hands can be solved, the means to do so are there, but we have to deal with "interface" issues ... plumbing problems. The non working compat ioctl is one, the fact that "sg" has no /sys/class/block (or /sys/block) entries is another, etc... Ie, we are faced with a problem with Linux not exposing those informations in an easy to retrieve way, and no proper cross-platform way to obtain those informations neither. > The whole problem would just go away if we could use the standard block > read()/write() calls here. Then the iovec would be placed _as > scatter-gather list_ on the request-queue and the block layer would take > care of the whole issue. That would be somewhat cheating with the concept of just being a SCSI transport layer :-) You would interpret some requests and turn them into something else. That would be "interesting" when your user starts using tags and make assumptions about what's in flight and what not etc... > I've tried to advocate this approach once, but (again) was being told > that it's a misuse of scsi-generic and I should be using scsi-disk instead. > > However, since Alex Graf is facing similar problems with the AHCI HBA of > his maybe we could retry again ... Again, I'd say different problems :-) To some extent scsi-disk will solve the issues with basic read/write operations, but there's some more nasty SCSI commands that you want through for things like DVD burning for example, unless we start building higher level abstractions into the kernel. So you -still- end up acting somewhat as a SCSI transport layer, and potentially hit the problem with limits again. Cheers, Ben. > Cheers, > > Hannes > -- > Dr. Hannes Reinecke zSeries & Storage > h...@suse.de +49 911 74053 688 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: Markus Rex, HRB 16746 (AG Nürnberg)
