A number of fixes are in the works. New approaches to tag command queuing, for example, have already been tested on a limited basis. The solution under development is moving this feature up into the SCSI generic segment, and taking it out of the specific SCSI device drivers. This solution so far is proving robust, and has allowed for some smaller device drivers, which means smaller modules to load and unload as needed.

On the issue of tag starvation, there seem to be a few different options hopping about in people's minds. One idea is to move tag starvation into the error handling code, keeping this problem down in the midlayer so that queuing issues need not go the inefficient route of passing back to the Upper Layer so commands can be re-sent.

The error handler could be used to watch a device's queue, and then "throttle" (block off access to) the queue when it fills or nearly fills. Once the queue has available room then more commands could be sent down in an orderly single file line with none of them ending up lost, or timed out. One of the existing (2.4.x) features that is supposed to help with tag starvation is the "host block driver function," but apparently there are still some bugs that need to be worked out here.

Another issue under discussion is better integrating the Linux kernel SCSI subsystem with the Linux kernel's Virtual Filesystem Switch (VFS) structure. VFS is the portion of the kernel "above" the SCSI subsystem that deals with filesystem actions. All VFS is concerned with is that you tried to take an action within the Linux filesystem, and it doesn't care whether that action was to print somethingwhich requires opening the file that needs to be printed, accessing its data, perhaps converting that data in some fashion, and then sending that data to the appropriate device driver for that printer--or change a filename.

Right now there is overhead with too many issues having to be passed all the way down to the SCSI subsystem, whether into the Upper, Middle, or Lower layers, and the efficiency gained by ensuring that VFS and the SCSI subsystem integrate better would both improve speeds and possibly shrink the kernel and modules slightly: after all, you'd hopefully be removing some redundancies.

Another inefficiency in this area is the way that commands are translated as they pass from VFS to the SCSI subsystem.

There is even talk about merging IDE and SCSI in some ways, especially in the ATAPI area regarding CD-ROMs (and this has already begun).

The most radical issues involve moving the Middle Layer into VFS, which would take the error handler into there as well. This is coming. Enterprise users rejoice!

Useful links

http://gear.torque.net/scsi/SCSI-2.4-HOWTO/
http://www.andante.org/scsidoc/SCSI-4.html

Dee-Ann LeBlanc has written over 10 computer books, over fifty articles, taught classes, and more, mostly involving the Linux operating system and its programs. You can follow her work and share your input through her new mailing list at http://www.dee-annleblanc.com/mailman/listinfo/general, or find out more in general at http://www.Dee-AnnLeBlanc.com/.

« Back: Introducing the Linux Kernel's SCSI Subsystem