Network Attached Storage & Object Oriented Devices

• Functionality
  • Device Organization
    • Space Organization
    • Object Identifiers (IDs)
    • Well Known Objects
    • Object
    • Navigating the Object File System
  • Device Functions
    • Open
    • Read
    • Write
    • Close
    • Remove
    • Create Partition
    • Remove Partition
• Manageability
  • Overview
  • Manageability Operations
    • Export Object
    • Get Object Attributes
    • Set Object Attributes
    • Device Lock Operations
    • Get, Set Device Associations
• Security Topics
  • Permissions
  • Cryptographic Support
  • Audit Trails
  • Clocks

Functionality

Data will be organized into fully self-defined and self-contained objects, which the storage device will be responsible for managing. Putting security aside for a moment, the object oriented architecture makes it possible for any Requester to inspect a device to discover what files exist there and request one or more, without knowing anything about the device's physical characteristics or even the operating system that created the object.

The object abstraction must not hide or otherwise make unavailable to a File Server or Requester information valuable to the optimal exploitation of the storage. For quality of service and self-manageability reasons, the object semantics should make available details of the device's capabilities without infringing on the device's sovereign self-management. For instance, a typical disc drive today has several strata of transfer rates. The specifics of these should be known to a degree sufficient to allow a policy to take advantage of them without affecting the device's space management mechanism. This could take the form of service levels and capacity quotas for each.

Objects look and work very much like traditional files. They are not the same. Files are constructed in an operating system context. They are often collected in a hierarchical directory structure, which again is operating system specific. Objects will be operating system independent, with (almost) any OS able to overlay its file system on the object abstraction.

The following sections describe the functions that will be needed on a device to support objects. This is preceded by a short overview of how a storage device might organize the objects.

Device Organization

Space Organization

In order for object oriented devices to provide the same functionality as is delivered by an operating system with block oriented devices, the storage space must be manageable to a similar degree and the OODs will have the constructs to do that. This necessitates having an organization layer on the OODs above objects. It is almost universal that operating systems provide for allocating disc space into one or more mutually exclusive regions, called partitions. The same should be available on OODs. Within a partition, a Requester can create objects. There is a single list of objects for each partition; any directory hierarchy is overlaid on the OODs' OFS by the operating system. This makes it possible for any operating system to use this method and makes much easier the use of one device by multiple operating systems.

The structure within a partition is envisioned to be a simple, flat organization. Onto this, any operating system can map its OS structures. An unsigned integer of some specified size will be the permanent signature for a given object on a device. Associated with this will be a certain number of blocks.

The device will maintain an object list for each of its partitions and space management information for the entire device.

While there will likely always be a need to support the BODs and relative sector addressing, there is a definite security problem with allowing a device to switch from an OOD to a BOD and back. To insure data security, the change from a BOD to an OOD must – and the change from an OOD to a BOD should – obliterate any object organization on the device.

Object Identifiers (IDs)

The identifier associated with an object is chosen by the device and returned to the Requester in response to the command to create an object. The ID will be an unsigned integer of a specified length. The length could default to a size set by the drive, or it could be set as a device attribute. A subset of IDs would be reserved for well known objects, special uses, and special functions.

Well Known Objects

A well-known Object is one that always has a specific object ID. In some cases it must exist on every device or in every partition. Using these IDs starts the Requester traversing the OFS. The following list has possible Object identifiers associated with each for illustration purposes.

Device Control Object (DCO) – Object 1

This object contains the attributes the OOD must maintain that relate to the device itself or that relate to all objects on the device. The attributes are maintained by the SET ATTRIBUTE function. There will be one DCO per device.

Figure 6: Possible Device Control Object Attributes

Partition Control Object (PCO) – Objects 2 - 255

This object contains the properties of a single partition. It describes not only the partition but also any object attributes that pertain to all in the partition. The OOD will have one PCO for each partition defined on the device.

Figure 7: Possible Partition Control Object Attributes

Partition Object List (POL) – Object 1 in Partition n

When a partition is created, a second well-known object will also be built – the point of departure for navigating the OFS. It will have the same identifier in every partition. This object consists of a list of the object IDs for all objects resident in this partition. The user will have the option to allocate user space associated with each ID.

Figure 8: Possible Partition Control Object Attributes

Object

Associated with every object in a partition is a set of attributes. The following is the set of attributes posited by CMU. The length of each attribute is a Seagate estimate.

Figure 9: Possible Object Attributes

Device Association Memberships (MDA) – Objects 256 - n

To adequately manage objects spanning multiple OODs, there will be an object describing an association. An important facility is the ability to define cross OOD relationships. Devices already intercommunicate; there will likely be even more of this in an OOD environment. The MDA defines all OODs that are members of a particular association of OODs. This could be used for something like mirror paired devices or a RAID set.

Figure 10: Possible Device Associations Object Attributes

Navigating the Object File System

Figure 11: Steps to finding an Object in a Partition

This illustration uses the Object IDs posited in the above descriptions. The first access to the device should be to get the device attributes. Since the device itself is not within a partition of the device, the partition ID used in the GET ATTRIBUTE command is zero (0). The Object ID is also zero (0). The returned information identifies the number of partitions, which can each be inspected with GET ATTRIBUTE commands for each partition of interest, using the appropriate partition ID and an Object ID of zero (0).

When Objects in a specific partition are of interest, the POL is used to get a list of those Objects. An OPEN on the ID from the POL will start the Requester using the OBJECT.

Device Functions

The OOD must support requests to provide or store data for a Requester. Moreover, it must assume responsibility for other functions that would have been done somewhere else – most likely in the operating system – in a BOD architecture. Space management, as well as the maintenance of attributes associated with the objects, will have to be done by the device.

The following are the operations that an OOD will have to perform as its contribution to the NAS environment. Each description lists the service provided by that function and the information that must be passed to the drive in order for the drive to perform that function. The information that could be returned by the device to the Requester is also listed to develop a clearer idea of what the function entails.

Open

This will communicate to the device the fact that a certain Object is to be accessed or a new one created. It will also indicate the kind of operations to be performed on the object. The OPEN offers the opportunity to deliver to the OOD valuable information. It introduces the fact that a new object will be created, for which the device must take some action. It can set quality of service attributes or thresholds, which lets the device inform the Requester if the service cannot be provided. For instance, if a new object has a minimum degree of contiguity, an OPEN parameter could direct the device to allocate space in units of that size.

Open-Create

The OPEN-CREATE will cause the device to allocate another Object ID, which will be returned. This the Requester will use to issue writes to the new object. In addition, the Requester can specify several options, among which might be:

• Make this file password protected
• Quality of service thresholds
• Encrypt this object
• Specify lock level – such as sector as well as object lock
• Specify versioning
• Mirror support – cause all updates to be mirrored onto another object
• Allocate space in units of a specified minimum size
• Set rights (as in UNIX)

The needed information includes:

• Permission information
• Partition of the device in which the object is to be created
• Options

The information returned could include:

• Quota or capacity available on the device
• Status of request
• ID of new object

A special instance of this command includes all data associated with an Object, so that in one command an object can be created, written, and closed.

Open-Update – includes extend

The OPEN-UPDATE will allow the Requester to read and write the specified Object. This also provides for extending the length of the object.

The needed information includes:

• Permission information
• Partition ID
• Identifier of the object to be accessed
• Type of action to be taken: Update
• Options

The information returned includes:

• Status of request
• Length of Object
• Quota or available capacity

Open-Read only

The OPEN-READ is obvious. It allows no writing to the file.

The needed information includes:

• Permission information
• Partition ID
• Object ID
• Options

The information returned includes:

• Status of request
• Length of Object

Read

The device is requested to return data from the specified object.

The needed information includes:

• Permission information
• Object identifier
• Options
• Partition ID
• Starting location of blocks to be read
• Number of blocks to be read

The information returned includes:

• Status of request
• Length of data
• Data

Write

This will cause the specified number of blocks to be written to the designated object at the relative location also specified. Information required is similar to that for a READ. A WRITE might also cause other events to occur. If parity support was called for on the target device, a write could automatically cause an XOR to be performed on the data and the parity data to be written to one or more previously specified parity devices (through a DA).

An option on this function would cause all outstanding writes that have not been physically put on the media to be written.

The needed information includes:

• Permission information
• Object identifier
• Partition ID
• Starting location of blocks to be written
• Number of blocks to be written
• Options
• Data

The information returned includes:

• Status of request

Close

This will cause the Object to be identified as no longer in use by a given Requester. Any changes as a result of writing to the Object, if not already written to the media, will be written at this time. The attributes for a newly created object will be updated at this time. The CLOSE could also specify the residual cache status in the Requester. If the Requester can inform the OOD that data is still being cached for the closed Object or no longer being cached, the OSs can retain cache information for those applications where files will be closed and opened again in quick succession. At the same time, the device will be able to keep track of who may have to be informed in the event of coherency collisions, should another Requester request access to this Object.

The needed information includes:

• Permission information
• Object identifier
• Options

The information returned includes:

• Status of request

Remove

Delete the Object. The ID becomes usable again.

The needed information includes:

• Permission information
• Partition ID
• Object identifier
• Options

The information returned includes:

• Status of request

Create Partition

Partition the drive into one or more regions. All space need not be accounted for. Regions can also span zones. The operation would implicitly establish an Object list for the partition.

There are two orthogonal uses for partitions. The first is a tiling arrangement with partitions true divisions of the storage space on a device. This would be used to divide the space by service levels, such as data rate. They could not be resized but could be removed and recreated. The second is a logical partitioning where the intent is more to organize the objects than manage the space. These partitions could be resized dynamically.

Regardless of the type of partitioning, this function will also create POL, which cannot be removed. This object will serve as the starting point for navigating the objects in the partition.

The needed information includes:

• Permission information
• Options
• Partition ID
• Initial space allocation

The information returned includes:

• Status of request
• Partition map

Remove Partition

This is the function that will remove a partition and implicitly delete the POL. Any Objects listed in this POL will be deleted.

The needed information includes:

• Permission information
• Options
• Partition ID

The information returned includes:

• Status of request
• Partition map