Atomic Commands Part III: Atomic Vectored Commands

The real value of vectored commands and atomic commands becomes apparent when they are combined into vectored atomic writes. A database update that requires multiple writes to update a record (e.g., multiple data fields or a data filed and links) will be significantly speeded if the writes can be performed in an vectored write command can be performed atomically. In this case, all of the data segments defined in the vectored command are either all completed successfully, or if an error occurs, they are all restored to their original values before the atomic write was attempted. In other words, if the vectored write operations succeed, all of the data segments will contain the new data. If not, all of the data segments will contain the data they had before the vectored write operation was attempted. This aggregation of writes along with the atomicity properties can lead to a significant improvement in data base performance.

So, what’s the problem?

First, there are issues with vectored commands around error reporting. When if one of the segment writes fails, how do you tell the initiator where the command failed? If the writes are all atomic, it doesn’t matter since they are all the old data. While it is interesting to note the position of the error for failure analysis, but that can be obtained through a variety of ways, including vendor specific methods.

Another problem is related to support for bi-directional commands. Here’s a flow diagram for a typical, non-vectored READ command:

Vectors Figure 2

And here’s the flow for a vectored read command:

Vectors Figure 3

In this case the initiator needs to send the segment descriptor list to the target (a data out phase) and then turn the bus around to receive the incoming data (a data in phase), which a bi-directional SCSI command. This has been the single biggest objection to vectored commands. Many implementations of SCSI transports were not designed to accommodate this type of bus transaction. And it’s not just a firmware change – much of this low level processing has been embedded in SCSI controller state machines.

Finally, implementing vectored atomic write operations is difficult in both traditional rotating media and in array controller systems. For these types of systems, the expense and maintenance of such functionality simply does not make economic sense. But for flash memory based storage systems typically use some sort of write logging mechanism, implementing this functionality is remarkably easy.

…to be continued…