Disk Interfaces

At the time of the database machines, hosts were responsible for much more of the detailed control of the disk drive than they are today. The use of higher-level, more abstract, interfaces to storage have moved much of this detailed control function (e.g. head positioning, track following, and sector layouts) to the on-drive processors discussed above, thereby offloading the host to perform more application-level processing tasks.

The standardization and popularity of SCSI has greatly helped the development of storage devices by providing a fixed interface to which device drivers could be written, while allowing devices to optimize “underneath” this interface. This is true at the individ- ual device level, as well as in groups of devices (such as RAID arrays, for example), which have taken advantage of the standardization of this interface to simply “act like” a single device and provide the same interface to the higher-level filesystem and operating

system code that are not aware that they are really dealing with a group of devices. But this interface is specified at a relatively low level, and has not been updated in many years. One of the contentions of previous work on Network-Attached Secure Disks (NASD) is that the simple block-level interface of SCSI should be replaced by a richer

object interface that allows the drives to manage more of their own metadata [Gibson97a].

This allows both offloading of the host and provides additional opportunities for optimiza- tion at the devices. In this system, a particular filesystem built on top of network-attached disks decides how to map user-level “objects”, such as files, directories, or database tables onto the “objects” provided by the object interface. A particular filesystem may choose to map multiple files or directories to the same object, or it might split a particular file over several objects, depending on particular semantics or performance characteristics, but the most straightforward approach maps a single file to a single object at the device. The drive is then responsible for managing the block layout of this object itself. This for the first time gives the drive knowledge of which blocks make up a user-understood unit of access. The drive can now understand and act on information such as “I am going to read this entire file” because it has a notion of what underlying blocks this refers to, whereas before only the filesystem at the host was aware of how variable-length files mapped onto fixed-size SCSI blocks. This also improves the efficiency of the higher-level filesystem, because it must no longer keep track of the usage and allocation of individual disk blocks. It can now reason in terms of objects and depend on the drive to “do the right thing” within this context. In a network-attached environment with shared storage, this means there is much less metadata update traffic that must take place. The mapping of objects to disk blocks is known only to the disks and must not be shared among multiple hosts that may be accessing or updating the same filesystem. Original SCSI disks had thousands of blocks, which were managed directly by the filesystems on the host, today’s drives have millions and tens of millions of blocks, so offloading the management of the lowest level of allocation to the drives is a reasonable step to take.

The object interface also provides a natural way to handle the security required by network-attached disks. It is no longer reasonable for a device to execute any command that is sent to it, as is true with SCSI devices today. The drive must have a way to authen- ticate that a particular request comes from a trusted party, that the requestor has the right to perform a particular action. Within NASD, this is done through a capability system [Gobioff97]. The file manager responsible for a particular device or set of devices shares a secret key with each of these devices. The file manager then hands out capabilities, which are cryptographically protected from tampering and which identify that a particular per- mission, or access right, could only have come from this file manager. Clients use these capabilities to access drives directly, without having to resort to the file manager on each access, as would be required with today’s file servers. When combined with the object interface, this means that security is handled on a per-object basis. The file manager does

not provide capabilities on a per-block basis, but provides a read or write capability for an entire object, which the clients can then use to read and write at their leisure.

The use of an object interface at the drives aids the development of Active Disks because application-level code operating at the drive can deal with an object as a whole. The on-drive code does not have to resort to a file server for metadata mapping or to pro- vide per-block capabilities. The on-drive code can obtain capabilities just as client code does and these can be shipped as part of the code to the drive. The on-drive code then acts as any other users of the drive and provides the appropriate capability whenever it wishes to access the object. This means that the security system that already protects unauthorized clients from destroying other users’ data also operates here. If a particular piece of on-drive code does not have the appropriate capability, then it cannot read or write the object. If it does have the appropriate capability, then it could just as well read or write the object remotely, so no additional security “hole” is opened up.