Objects of the object manager class are responsible for creating and maintaining IO objects of a specific type and responsibility. For instance, an IO object’s specific information is defined by the object manager (see MM_ReturnObjectSpecificInfo).
The partition APIs defined in Partition Management Functions provide methods into some of the object managers for enabling, removing, and modifying features provided by the object managers.
This section covers the following topics:
The registration of object managers is currently beyond the scope of this document.
An object manager object's generic information can be obtained by calling MM_ReturnObjectGenericInfo. The ObjectManagerGenericInfoDef structure is returned for the OBID.
Types of IO objects include adapter, device, media, partition, Hot Fix, mirror, clone, changer (auto-changer), magazine, and slot objects. Each will be discussed in greater detail in this section.
To obtain specific information structure definitions for each of the IO object types, see IO Function Operations.
Each object manager has a unique value used to define its type. This value is used by a variety of APIs where an IO object type is required. One example is MM_FindObjectType.
For the list of IO object type values, see IO Object Types.
The adapter and device object managers are registered with the Media Manager by the IO subsystem, NWPA. Device and adapter objects represent the physical hardware reported by the NWPA device drivers. In addition to the generic information of a device or adapter object, the AdapterSpecificInfoDef and DeviceSpecificInfoDef structures can be used to identify all the storage hardware available to the server. The adapter and device object managers provide the lowest level IO operations.
The media object manager mostly deals with the issues of removable media. Removable media can be created, deleted, labeled, moved, selected (in the case where media is in a magazine), ejected, etc.
The IO function operations are documented in IO Function Operations.
A media object’s specific information is the same as the DeviceSpecificInfoDef structure.
The partition object manager manages the partitioning of media. Currently only the DOS partitioning scheme is recognized and supported. Each partition defined in the DOS partition table has a partition object instantiated to represent it. If the DOS partition table does not exist (or is damaged beyond recognition), the partition object manager has the capability to initialize a DOS partition table and also to define or remove partition table entries, all according to the DOS definition.
Several partition types are recognized by the partition object manager; however, only those types relative to NetWare are defined in this documentation (see NetWare Partition Types).
The PartitionSpecificInfoDef structure fully describes a media partition. This structure contains the partition’s physical capacity, in sectors, as defined in the DOS partition table. This value might not be the same capacity value found in the IOObjectGenericInfoDef structure for the partition object. The value in the latter structure is a logical capacity, the amount available to an application, and can be smaller than the physical capacity.
The Hot Fix object manager adds value to the NetWare partition object by reserving some sectors on the partition as spares for faulty sectors in the remaining data area of the partition. The Hot Fix object represents an instance of this form of fault tolerance found on a NetWare partition.
The Hot Fix object manager places information in the NetWare partition that defines the amount of space used for spares. Other information required to recreate the Hot Fix object across NetWare server initializations is also placed there.
When a device driver reports a media failure, the Hot Fix object manager will assign a block of sectors from the pool of spare sectors to take the place of the faulty set. If the failure occurred on a write request, the data is placed in the spares and the IO request completes without an error. If the failure occurred on a read, however, then an attempt will be made to retrieve the data from the file system’s cache. If the data is not available, the IO request fails with a return value of MM_DATA_MISSING and will continue to return this value until new data is written to the now spare sectors
Prior to NetWare 5.0, Hot Fix was a required feature of all NetWare partitions. With NetWare 5.0, however, Hot Fix is now optional, because fault tolerant storage hardware is becoming so popular and typically much faster than software implementations of fault tolerance. It should be noted that Hot Fix should not be added to a partition after application data has been placed on the partition. Doing so would destroy any existing data on the partition.
The Hot Fix object's specific information is described in the HotfixSpecificInfoDef structure.
The mirror object manager adds value to the Hot Fix object by allowing up to eight NetWare partitions with Hot Fix to be mirrored. Any data written to the mirror object actually gets written to each NetWare partition in the mirror set. Read requests are also load balanced across the mirror set to increase IO performance.
Since the mirror object manager expects the objects in the mirror set to be Hot Fix objects, the NetWare partition must have Hot Fix on it before it can be a member of a mirror set.
It is possible to have a mirror object that is not mirrored. This means is that the mirror object has the potential to be mirrored. Mirror objects can be added and removed from mirror sets on the fly. Each time a mirror object is added to a mirror set, a mirror re-synchronization process takes place. The amount of time to re-synchronize is directly proportional to the capacity of the mirror object.
The mirror object's specific information is described in the MirrorSpecificInfoDef structure.
The clone object manager plays a small but vital role. When a mirrored mirror object is activated, a clone object is created as a place holder for each of the other Hot Fix objects in the mirror set not yet activated. A mirror set with only one activated Hot Fix object, and the remaining objects in the set being clones, is not fault tolerant. As the remaining Hot Fix objects in the set activate, they will replace their corresponding clone object.
The clone object does not have specific information.
The changer object manager is responsible for high level access to changer devices. When an IO subsystem creates a changer device, the changer object manager attaches a filter to it that provides operations such as inventory, MM_LOAD_FUNCTIONS, MM_MOVE_FUNCTIONS, etc.
The inventory operation causes each piece of media in the changer to be placed in a read/write device within the changer. The device is activated and the identify routines are called. When the inventory is complete, all media is identified and the changer object knows what media is in what slots.
A changer object has a slot mapping table, one slot in the table per slot within the changer, one slot per mail box, or portal through which media is entered in or removed from the changer, and one slot per read/write device within the changer. The mapping table is an array of OBIDs. The OBIDs are either media or magazine objects, indicating the presence of media or a magazine in the corresponding slot, or slot objects, indicating an empty slot.
The changer object's specific information is described in the ChangerSpecificInfoDef structure.
The magazine object manager allows for the creation and management of magazines. It is similar in function to the changer object manager in that it has operations for inventory, MM_LOAD_FUNCTIONS, etc.
The magazine object has a slot mapping table, one slot in the table per slot in the magazine plus an additional slot to represent the read/write slot in the device that media is moved to (from a magazine slot) prior to performing IO. The mapping table is an array of OBIDs. The OBIDS are either media objects, indicating the presence of media in the corresponding slot, or slot objects, indicating an empty slot.
The device’s read/write slot is slot zero in the mapping table. Thus, if media is to be moved from the first slot in the magazine to the device’s read/write slot, then programmatically the media would be moved from slot 1 to slot 0.
The magazine object's specific information is described in the MagazineSpecificInfoDef structure.
The slot object manager is the most trivial of all. Objects of this manager simply indicate empty slots in a magazine or changer.
The slot object does not have specific information.