2003 Kernel Summit: SCSI [LWN.net]

This article is part of LWN's 2003 Kernel Developers' Summit coverage.

James Bottomley donned his bow tie to lead this session - a refreshing change from the normal kernel hacker dress code. His talk looked at the progress made on the SCSI goals adopted at last year's summit.

The first of these goals was the implemention of barriers for block I/O operations. Barriers using SCSI tagged operations have been implemented - at least for a few drivers - but they are not yet heavily used. There was a fair amount of discussion about how necessary these barriers really are in the SCSI world. Cheaper drives require barriers to assure the system that blocks have truly been written to disk; SCSI drives are generally expected to work more reliably than that. It was pointed out, though, that a lot of things that look like SCSI drives are really something else - USB drives, for example, or IDE drives using Jeff Garzik's new ATA driver. The conclusion that barriers should continue to be passed down into the low-level drivers which can then make their own decisions as to if and how they should be implemented.

Persistent naming of SCSI drives was an issue last year; the SCSI developers implemented it, decided they didn't like it, and ripped it out. The real solution is to handle persistent naming in user space, via the hotplug mechanism.

Hotplug support was also an issue; the basic support is there, but there are still a number of things to clean up. Interactions with other subsystems (such as USB) are an ongoing challenge.

Error handling was a big item last year. A lot of work has been done in this area, but much remains. There is a real need for better error handling information in both directions; support of features like multipath I/O, software RAID, and asynchronous I/O depends on it. Two things are needed, according to James:

An indication of error-handling policy, passed down from the higher layers. Should the low level driver attempt to retry operations on errors, or simply give up and return a failure code?
Information on actual errors, passed up from the lower levels. Higher-level logic needs to know about the specific type of the error - was it in the drive or the transport, for example? Is it something that can be retried? And so on.

Linus suggested that the whole problem could be solved by adding a maximum retry count to the BIO structure describing block operations and an error code which is passed back up.

Last year's summit concluded that much of the SCSI mid-layer functionality should be migrated into the block layer. James reported that this job is mostly complete - but most of the features are still used only by SCSI. There is still work to be done in bringing the SCSI and IDE subsystems closer together.

Other topics included improving SCSI command allocation ("under control"), lazy allocation (not yet done), user-level scanning via the hotplug mechanism (not done), and fixing the queueing problems, which is mostly done.

The session concluded with the revelation that it is James's birthday; a rousing chorus of "Happy Birthday" was sung in his honor.

(Log in to post comments)