Read-Multiple(WORM) archive. Each object corresponds to a single stream of data and a
singleset of metadata; there are no “grouped objects” or “compound objects” other than by
applicationconvention.
Eachobject corresponds to a single stream of data and a single set of metadata. There are no
“groupedobjects” or “compound objects” other than by application convention. Similarly,
thereare no “links” or “associations“ from one object to another. The customer application is
shieldedfrom all details of how or where the object is stored. Internally, the actual location of an
objectmight change over time, or several objects might even share the same underlying storage.
Thecustomer application can retrieve the object without knowing these details.
Astream of data is stored in the object archive using storeObject. Once stored, each such
objectis associated with an object identier or objectid (OID). The storeObject operation takes
botha stream of data and an optional set of user metadata information and returns an OID. The
OIDcan be remembered outside of the 5800 system and may later be used to retrieve the data
associatedwith that object using the retrieveObject operation.
Everyobject has metadata whether or not user metadata was supplied at the time of the store.
Forexample each object has system metadata that is system assigned and can never be modied
bythe user. The OID is associated with the metadata record that represents this object as a
whole;the metadata record is then associated with the underlying data:
OIDMetadata Record Underlying Object Data
TheretrieveObject operation takes an OID as input and returns a stream of bytes as output
thatare identical to the bytes stored during the storeObject operation. Both the storeObject
andretrieveObject operations handle the data in a streaming manner. Not all of the data need
bepresent in client memory or in server memory at the same time, which is a crucial point for
workingwith large objects.
Forthe 5800 system Release 1.1, data sizes up to 400 GBytes are tested and supported. Using
sizeseven smaller than this may be appropriate as a best practice. For more information, see
Chapter5, “Programming Considerations and Best Practices.”
Fromwithin a customer application, the storing of an object into the archive is an
all-or-nothingevent. Either the object is stored or it is not; there are no partial stores. If a store
operationis interrupted, the entire storeObject call fails. Once an OID is returned to the
customerapplication, the object is known to be durable. In the event of an outage that causes
somedata loss, the system should be no more likely to lose a newly stored object than any other
object.There is no way to tie together two dierent store operations so that both either succeed
togetheror fail together.
Note– A stored object may or may not immediately be queryable. For more information, see
“The5800 System Query Integrity Model” on page 21.
5800SystemOver view
SunStorageTek5800 System Client API Reference Manual • June 200818