Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS5983283 A
Publication typeGrant
Application numberUS 08/632,217
Publication dateNov 9, 1999
Filing dateApr 15, 1996
Priority dateApr 15, 1996
Fee statusPaid
Also published asDE69700895D1, EP0802478A1, EP0802478B1
Publication number08632217, 632217, US 5983283 A, US 5983283A, US-A-5983283, US5983283 A, US5983283A
InventorsSteven T. Senator, Dale R. Passmore, Robert S. Gittins
Original AssigneeSun Microsystems, Inc.
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Storage manager independent configuration interface translator and method
US 5983283 A
Abstract
A system, method and computer program product comprising a storage manager independent configuration interface translator which requests an opaque listing of the available storage devices from an associated metadisk driver and determines a subset of the listing meeting a preselected search criteria. The resultant opaque listing is then converted to a non-opaque format listing for presentation to a user of the computer system in a desired format such as through a command line or graphical user interface. A notification mechanism is also provided that presents information about storage devices which have in some way changed while in use.
Images(2)
Previous page
Next page
Claims(11)
What is claimed is:
1. A method for computer mass storage management in a computer system having an operating system and physical storage devices that are operatively controlled by mass storage device drivers, said mass storage device drivers being operatively controlled by metadrivers, said method comprising the steps of:
providing at least one user interface;
providing a generic storage manager library configuration block that is both storage manager independent and software release independent, said library configuration block interfacing with said operating system, and receiving inputs from and passing outputs to said at least one user interface;
providing a metadisk driver coupled intermediate said library configuration block and said metadrivers;
providing a database associated with said metadisk driver, said database containing information corresponding to said physical storage devices;
providing for requesting an opaque listing of said physical storage devices from said metadisk driver and said database by a given user of said computer system using said at least one user interface;
providing for determining a subset of said opaque listing of said physical storage devices meeting a preselected search criteria defined by said given user of said computer system;
providing for converting said subset of said opaque listing of said physical devices to a non-opaque format listing; and
providing for presenting said non-opaque format listing to said given user of said computer system by way of said at least one user interface.
2. The method of claim 1 wherein said at least one user interface is selected from the group command line interface and graphical user interface.
3. The method of claim 1 including the step of:
providing for notifying users of said computer system of any status change of said physical storage devices through said non-opaque format listing and by way of said at least one user interface.
4. A computer program product having a computer useable medium with computer readable code embodied therein, said computer usable medium for use in implementing computer mass storage management in a computer system, said computer system having an operating system, at least one user interface, physical mass storage devices that are controlled by device drivers, metadrivers that control said device drivers, a metadisk driver that controls said metadrivers, and a database that is associated with said metadisk driver and contains information corresponding to said physical mass storage devices, said computer readable codes devices comprising:
first computer readable program code devices to effect providing a generic library configuration block between said metadisk driver and said at least one user interface, said library configuration block being operating system independent, said library configuration block receiving user inputs from said at least one user interface, and said library configuration block passing outputs to said at least one user interface;
second computer readable program code devices configured to enable said at least one user interface to effect requesting an opaque listing of said physical mass storage devices from said metadisk driver and said database;
third computer readable program code devices configured to enable said at least one user interface to effect determining a subset of said opaque listing of physical mass storage devices in accordance with a search criteria that is selected by a user of said computer system;
fourth computer readable program code devices configured to effect converting said subset of said opaque listing of physical mass storage devices to a non-opaque format listing; and
fifth computer readable program code devices configured to cause said at least one user interface to effect presenting said non-opaque format listing to said user.
5. The computer program product of claim of claim 4 wherein said at least one user interface is selected from the group command line interface and graphical user interface.
6. The computer program product of claim 4 further comprising:
sixth computer readable program code devices configured to enable said at least one user interface to effect notifying said user of any status change of said physical mass storage devices by way of said non-opaque format listing.
7. The computer program product of claim of claim 6 wherein said at least one user interface is selected from the group command line interface and graphical user interface.
8. A system for the management of physical mass storage devices in a computer system having an operating system, a metadisk driver that operatively controls underlying metadrivers that operatively control underlying mass storage device drivers that operatively control underlying physical mass storage devices, said system comprising:
a database associated with said metadisk driver, said database containing information corresponding to said physical mass storage devices;
a library configuration block in operative association with said operating system, said library configuration block being coupled to said metadisk driver through said operating system;
at least one user interface block coupled to said library configuration block for providing data input thereto and receiving data output therefrom; and
said library configuration block being responsive to data input from said at least one user interface and operating to request an opaque listing of said physical mass storage devices, determine a subset of said opaque listing meeting a search criteria according to said data input, convert said subset of said opaque listing to a non-opaque format listing, and provide said non-opaque format listing as data output to said at least one user interface block.
9. The system of claim 8 further comprising:
a notify block in operative association with said metadisk driver for providing information to said metadisk driver regarding changes in status of said physical mass storage devices for presentation to said library configuration block and for presentation as output data to said at least one user interface.
10. The system of claim 8 wherein said opaque listing comprises at least one storage descriptor.
11. The system of claim 10 wherein said at least one storage descriptor further comprises at least one non-opaque storage descriptor identifier.
Description
CROSS REFERENCE TO RELATED APPLICATIONS

The present invention is related to the subject matter of United States Pat. No. 5,802,364 for "Metadevice Driver Rename/Exchange Technique for a Computer System Incorporating a Plurality of Independent Device Drivers" and Ser. No. 08/632,546 for "Event Notification in a Computing System Having a Plurality of Storage Devices" filed on even date herewith and assigned to Sun Microsystems, Inc., assignee of the present invention, the disclosures of which are hereby specifically incorporated herein by this reference.

BACKGROUND OF THE INVENTION

The present invention relates, in general, to the field of computers and computer operating systems for operatively controlling a plurality of computer mass storage device drivers coupled to a computer operating system through a metadevice or metadisk driver. More particularly, the present invention relates to a system, method and computer program product comprising a storage manager independent configuration interface translator

Currently available storage manager programs for computer systems are generally release dependent. That is, they must be expressly designed for use with particular releases of an associated computer operating system. Moreover, existing storage manager programs have generally been tied to a particular developer's operating system and have not been able to function as an extensible, generic storage management product to apprise a user of the storage devices available for use and their configuration as part of larger groups of storage devices. Still further, existing programs have not been able to provide an acceptable notification mechanism for queuing any changes in the status of the underlying storage devices.

SUMMARY OF THE INVENTION

The present invention advantageously provides an extensible, generic interface to a computer mass storage management system that presents a catalog, or listing, of storage devices available for use and their configuration, whether as part of a redundant array of inexpensive disks ("RAID"), mirrored set or other groups (or sets) of devices. It also conveniently provides an event notification mechanism to present information about any changes in the identity, configuration, status or utilization by other hosts of the underlying storage devices. In a preferred embodiment, the present invention may be implemented as a portion of the Solstice™ DiskSuite™ program and may also be utilized in conjunction with other available storage managers such as the Veritas™ volume manager and the IBM logical volume manager.

The storage manager independent configuration interface translator disclosed herein utilizes a group of opaque storage descriptors which may be queried by accessor functions to determine, for example, error conditions, device set relationships and the like. The storage descriptors each have an associated storage descriptor identifier ("SDID") which are linked and function as publicly accessible (i.e. non-opaque) keys by an associated command line interface ("CLI") or graphical user interface ("GUI").

In a specific embodiment disclosed herein is a method for computer mass storage management in a computer system incorporating a metadisk driver and associated database containing information corresponding to devices operatively controlled by metadrivers coupled to the metadisk driver. The method comprises the steps of requesting an opaque listing of the devices from the metadisk driver and determining a subset of the opaque listing of devices meeting a preselected search criteria. The subset of the opaque listing is converted to a non- opaque format listing and is presented to a user of the computer system.

BRIEF DESCRIPTION OF THE DRAWINGS

The aforementioned and other features and objects of the present invention and the manner of attaining them will become more apparent and the invention itself will be best understood by reference to the following description of a preferred embodiment taken in conjunction with the accompanying drawings, wherein:

FIG. 1 is a simplified representational drawing of a general purpose computer forming a portion of the operating environment of the present invention;

FIG. 2 is a simplified conceptual representation of an exemplary computer program operating system incorporating a storage manager independent library configuration ("libconfig") block for operative coupling to a plurality of metadrivers through a metadisk driver as herein disclosed;

FIG. 3 is a simplified conceptual representation of a number of storage descriptors, each having an associated storage descriptor identifiers ("SDID"), which may be conceptually "anchored" to the command line interface ("CLI") or graphical user interface ("GUI") of FIG. 2.

DESCRIPTION OF A PREFERRED EMBODIMENT

The environment in which the present invention is used encompasses the general distributed computing system, wherein general purpose computers, workstations or personal computers are connected via communication links of various types, in a client-server arrangement, wherein programs and data, many in the form of objects, are made available by various members of the system for execution and access by other members of the system. Some of the elements of a general purpose workstation computer are shown in FIG. 1, wherein a processor 1 is shown, having an input/output ("I/O") section 2, a central processing unit ("CPU") 3 and a memory section 4. The I/O section 2 may be connected to a keyboard 5, a display unit 6, a disk storage unit 9, a CDROM drive or unit 7 or a computer network 11 such as a wide area network ("WAN"), local area network ("LAN") or other network connection such as the Internet. The CDROM unit 7 can read a CDROM or CDROM medium 8 which typically contains programs 10 and data. The computer program products containing mechanisms to effectuate the apparatus and methods of the present invention may reside in the memory section 4, or on a disk storage unit 9 or on the CDROM 8 or network 11 of such a system.

With reference now to FIG. 2, a simplified conceptual representation of an exemplary computer program operating system 20 is shown. The computer operating system 20 incorporates a storage manager independent library configuration ("libconfig") block 26 which receives inputs and passes outputs to a command line interface ("CLI") 22 as well as a graphic user interface ("GUI") 24. The libconfig block 26 is designed to be storage manager independent and software release independent.

The libconfig block 26 interfaces with a libmeta block 28 which is subject to change dependant upon the requirements of a particular software release and is generally designed for a particular storage manager. In the illustration shown, libmeta block 28 includes a unique interface 30 for communication with a metadisk driver 36 having a similar interface 30. The libmeta block 28 and metadisk driver 36 communicate through the user 32 and kernel 34 layers of the operating system 20. As shown, the libconfig block 26, because it is storage manager independent, is able to communication directly with an alternative storage manager 38 in lieu of metadisk driver 36.

Metadisk driver 36 (which is more fully described in the co-pending patent applications referenced earlier) has an associated database 40 which may interface with a slice (or partition) of a storage device through a DDI/DKI interface in a UNIX™ based operating system 20, such as the Solaris™ operating system available from Sun Microsystems, Inc., assignee of the present invention.

The metadisk driver 36 overlies a number of metadrivers corresponding to various computer mass storage devices and configurations as shown. In this regard, a stripe metadriver 42, a mirror metadriver 44, a RAID metadriver 46 and a trans metadriver 48 may be used. It should be noted, however, that these various metadrivers 42-48 are merely exemplary and not intended to limit the types of metadrivers, layered drivers, or other computer mass storage drivers which might be utilized. The metadisk driver 36 also has an associated notify block 50. The notify block 50 functions as a rendezvous point for queued messages regarding storage device related events such as information about any changes in the identity, configuration, status or utilization by other hosts of the underlying storage devices.

With reference now to FIG. 3, a simplified conceptual representation of a number of opaque (or non-public) storage descriptors 60 is shown which may be coupled through a conceptual "anchor" 52 to the CLI 22 and GUI 24. The storage descriptors 60 each are associated with a publicly accessible (or non-opaque) storage descriptor identifier ("SDID") 62, as shown which function as keys and allow the CLI 22 or GUI 24 to view their contents through the mechanism of the anchor 52.

The following functions are described in greater detail to more fully illustrate the functionality of the storage manager independent configuration interface translator and method disclosed herein in conjunction with the particular implementation used in the Solstice™ DiskSuite™ 4.0 computer program developed and licensed by Sun Microsystems, Inc., assignee of the present invention. The initial listing which follows relates to a function which may be utilized for obtaining a set name list:

______________________________________NAME           cfg-- get-- setname-- list,                      cfg-- destroy-- setname-- list,          - obtain or                      destroy a vector of set names for the                      local hostSYNOPSIS               #include <config.h>                      int cfg-- get-- setname--          list(char                      ***et-- name-- list-- p)                      void cfg-- destroy-- setname--          list(char                      **set-- name list)DESCRIPTION         These functions allocate or destroy a                      vector of set names that are known to                      the DiskSuite subsystem on the local                      host, respectively.ARGUMENTS             set-- name-- list-- p                      This is the address of a vector of                      character strings which are allocated                      by cfg-- get--  setname-- list(          ) and set                      equal to the names of sets which are                      defined on this host.                      set-- name-- list                      This is the vector of character                      strings which was allocated by                      cfg-- get-- setname-- list( ).RETURN VALUES     Upon success, a value of 0 is                      returned. Otherwise the return value                      is an errno, as in intro                      (2).______________________________________

The following functions relate to the construction of an opaque object list:

______________________________________NAME         cfg-- getsd-- by-- id,                    cfg-- getsd-- by-- setname,        cfg-- getsd-- next,                    cfg-- getsd-- rewind, cfg--        getsd-- toplevel,                    cfg-- destroy-- sd - read and        manipulate                    storage descriptorsSYNOPSIS          #include <config.h>                    int                    cfg-- getsd-- by-- id(sdid--        t sdid, void                    **storage-- descriptor-- pp)                    int                    cfg-- getsd-- by-- setname(char        *setname,                    void **storage-- descriptor-- pp)                    int                    cfg-- getsd-- next(void                    **storage-- descriptor-- pp)                    int                    cfg-- getsd-- rewind(void                    **storage-- descriptor-- pp)                    int                    cfg-- getsd-- toplevel(sdid-- t        sdid, void                    **storage-- descriptor-- pp)                    int                    cfg-- destroy-- sd(void                    *storage-- descriptor-- p)DESCRIPTION         These functions manipulate storage                    descriptors, storage descriptor                    identifiers and textual storage                    descriptors. Storage descriptors                    describe the objects which contain                    storage without exposing internal                    DiskSuite interfaces or data                    structures.                    cfg-- getsd-- by-- setname( )                    sets its argument                    storage-- descriptor-- pp to refer to        an                    allocated list of storage descriptor                    pointers. This list may be walked                    using cfg-- getsd-- next( ) or                    repositioned to the list head with                    cfg-- getsd-- rewind( ).                    cfg-- destroy-- sd( )                    deallocates the list that was                    allocated by cfg-- getsd-- by--        setname( ).                    cfg-- getsd-- by-- id( )                    is used reposition the storage                    descriptor list to the entry                    identified by sdid.                    cfg-- getsd-- toplevel( )                    is used to obtain the uppermost          containing object. Since some objects          are orphans, the appropriate set          contains all such otherwise          unattached objects          For normal storage devices, mirrors          would contain the stripes which make          up its sub-mirrors, for example.          cfg-- getsd-- next( )          is used to set storage-- descriptor-- pp          to the next element in the list. At          the end of the list it is set to          NULL.          cfg-- getsd-- rewind( )          resets storage descriptor-- pp to the          beginning of the list. This is most          useful just before calling          cfg-- destroy-- sd( ).ARGUMENTS         setname          This is a NULL-terminated character          string which identifies the set for          which storage descriptors are to be          obtained.          storage-- descriptor-- pp          This is the address of a void pointer           which will be allocated by          cfg-- getsd-- by-- setname, manipulated by          one of the following cfg-- getsd-- by--        id,          cfg-- getsd-- next,          cfg-- getsd-- rewind ,           cfg-- getsd-- toplevel or de-allocated by          cfg-- destroy-- sd          storage-- descriptor-- p                  This is the current position of the                  storage-- descriptor list as obtained                  from cfg-- getsd-- by-- setname.                  sdid                  This is a public interface to the                  contents of a storage descriptor.                  Described fully in cfg-- get-- sdid,                  it is usually obtained from the event                  handling routines.RETURN VALUES             Upon success these routines return 0.                  Upon an error, the appropriate error                  number from intro                  (2) is returned.______________________________________

The following functions determine the attributes of opaque objects and whether or not they are of interest:

______________________________________NAME          cfg-- validate-- sd, cfg-- sd--         is-- err,                    cfg-- sd-- is-- owned, cfg--         sd-- is-- toplevel -                    check validity and attributes of a                    storage descriptorSYNOPSIS            #include <config.h>                    int                    cfg-- sd-- is-- err(void                    *storage-- descriptor-- p)                    int                    cfg-- sd-- is-- owned(void                    *storage-- descriptor-- p)                    int                    cfg-- sd-- is-- toplevel(void         *storage                    descriptor-- p)                    int                     cfg-- validate-- sd(void                     *storage-- descriptor-- p)DESCRIPTION    These functions check the validity or                     attributes of a given storage                     descriptor.ARGUMENT           storage-- descriptor-- p              This is the current value of the              storage descriptor list obtained from              zone of cfg-- getsd-- by-- id( ) or              cfg-- getsd-- by-- setname( ).              cfg-- sd-- is-- err( )              returns TRUE (non-zero) if there is              an error in the associated devices              state.              cfg-- sd-- is-- owned( )              returns TRUE (non-zero) if the              storage descriptor refers to an              object which may or may not be owned              by a given host. These include              objects of type MDSD-- HOST and              MDSD-- SET.              cfg-- sd-- is-- toplevel( )              returns TRUE (non-zero) if the              storage descriptor refers to an              object which is not contained by any              other storage descriptor. Examples              of top-- level devices include the set              entry and mirrors which contains sub-              mirrors              cfg-- validate-- sd( )              may be used to verify the contents of              a given storage-- descriptor. This is              useful to verify that wild pointers              have not written over its contents              and to verify that it hasn't been              deallocated. It returns TRUE (non-              zero) if the storage-- descriptor-- p is              valid.              All of these routines return FALSE on              any error condition.______________________________________

The following functions compare and retrieve the public identifiers ("SDID"):

______________________________________NAME                    cfg-- cmp-- sdid, cfg-- destroy.sub           .-- sdid,                     cfg-- get-- sdid, --- compare,           allocate                     and deallocate storage descriptor                     identifiersSYNOPSIS             #include <config.h>                     sdid-- cmp-- t                     cfg-- cmp-- sdid(sdid-- t sl,           sdid-- t s2)                     int                     cfg-- get-- sdid(void *storage-                  descriptor-- p), sdid-- t *sdidp)                     int                     cfg-- destroy-- sdid(sdid-- t           *sdidp)DESCRIPTION       These functions manipulate storage                     descriptor identifiers, which are the                     public key to storage descriptors.                     cfg-- get-- sdid ( )                     translates the data within                     storage-- descriptor-- p and fills in           the                     values into sdidp.                     storage-- descriptor-- p may be           obtained                     from one of the cfg-- getsd-- *                     functions.                     cfg-- destroy-- sdid ( )                     returns any memory that was allocated                     within the sdidp by cfg-- get-- sdid           ( ).                     It does not deallocate                     cfg-- cmp-- sdid ( )                     allows sdid-t's to be compared. It                     returns one of the following                             enumerated types, according to the                     following type definition.                     typedef enum sdid-- compare {                     SDIDCM-- UNK,                     SDIDCMP-- NO,                     SDIDCMP-- EXACT,                      SDIDCMP-- STALE,                      SDIDCMP-- TYPE}               sdid-- cmp-- t;                 SDIDCMP-- UNK                 An error occurred while attempting to                 compare sl, and s2. No comparison                 was made.                 SDIDCMP-- NO                 The two storage descriptor                 identifiers, sl, and s2, do not                 match.                 SDIDCMP-- EXACT                 The two storage descriptor                 identifiers, s1, and s2, are                 identical.                 SDIDCMP-- STALE                 The two storage descriptor                  identifiers describe the same object                  but the object is likely to have                  changed between the time when one or                  both of s1, and s2 were last checked                  against the driver's state.                  SDIDCMP-- TYPE                  The two storage descriptor                  identifiers match only in type of                  object, but otherwise are different.                  Storage descriptor identifiers                   (sdid-- t) are a public interface to                   the data within storage descriptors.                   They are usually obtained from the                   event handling routines. (Storage                   descriptor identifiers consist of                   enumerated types and unique keys for                   each object (see config.h.) as below.                   The fields which uniquely identify a                   storage descriptor are the sdi-- type,                             sdi-- key, and sdi-- ctime.       typedef struct storage-- descriptor-- id {       struct storage-- descriptor-- id *sdi-- next;       char       *sdi-- name;       char                               *sdi-- setname;       u-- longlong-- t                                  sdi-- user;       mdsdtyp-- t                                     sdi-- type;       u-- longlong-- t                                  sdi-- key;       time-- t                                        sdi-- ctime;       } sdid-- t;       Storage descriptor types are described by       one of the following enumerated values.     typedef enum md-- storage-- descriptor-- type {MDSD-- UNK = SDTYP-- UNK,           /*explicit illegal value*/MDSD-- USER,                    /*user-specified storage type*/MDSD-- UNSPEC,                       /*unspecified storage type*/MDSD-- STRIPE,                       /*block interleave/append*/MDSD-- MIRROR,                       /*block replication*/MDSD-- RAID5,                        /*striped parity*/MDSD-- TRANS,                        /*transacting device*/MDSD-- REPLICA,                      /*data base replica*/MDSD-- HSP,                          /*hot spare pool*/MDSD-- HS,                 /*hot spare member*/MDSD-- RESERVED,                     /*unavailable for use*/MDSD-- SET,                     /*administrative collection*/MDSD-- HOST,                    /* hosts able to own the set*/MDSD-- MEDIATOR                      /* arbitrator*/} mdsdtyp-- t;______________________________________

The objects described are all constructed pseudo-devices which provide a class of storage (ie. mirrored) or administratively-related entities.

______________________________________RETURN VALUES  Except for cfg-- cmp-- sdid, as described                      above, these functions return 0 upon                      success. Upon error, an errno is                      returned, as in intro (2). ep is                      filled in with the error information.______________________________________

The following functions convert opaque objects to a readable format:

______________________________________NAME          cfg-- get-- text-- sd, cfg-- destroy.sub         .-- text-- sd,allocate and deallocate textual                  storage descriptors textSYNOPSIS          #include <config.h>                  int                  cfg-- get-- text-- sd(void                  *storage-- descriptor-- p, sdtext--         t                  **sdtpp)                  int                  cfg-- destroy-- text-- sd(sdtext.sub         .-- t *sdtp)DESCRIPTION    These routines allocate and                  deallocate textual storage                  descriptors, respectively. Textual                  storage descriptors are printable                  versions of the information packeted                  within storage descriptors, which are                  themselves described in                  cfg-- getsd-- by-- id.ARGUMENTS        storage-- descriptor-- p                  This is a pointer to a storage                  descriptor as returned by                  cfg-- getsd-- by-- id ( ) or                  cfg-- getsd-- by-- setname ( ).                  sdtpp             This is the address of a pointer to a             textual storage descriptor.                  typedef struct                  storage-- descriptor-- text-- t {                  char *storage-- allocator-- name;                  char *name;                  char *type;                  char **attr;                  char **components;                  storage-- allocator-- name              is set to the identity of the storage              manager. The DiskSuite ™              implementation of the storage manager              independent configuration interface              translator and method of the present              invention available from Sun              Microsystems, Inc. sets this string              to "DiskSuite".              name is the pathname of this device                in the file system tree.              type is a string identifying the                     device, such as "mirror" or                     "RAID5."              attr is a vector of attributes (which                  may be NULL) set to the strings                     "error", "owned" or "toplevel."              components                     is a vector of component names.                     These are usually, but are not                     required to be, sub-devices such                     as cOt1dOs1.RETURN VALUES Upon success, these routines return              0. Otherwise an error is returned.______________________________________

The following functions are event related:

______________________________________NAME           cfg-- ev-- create, cfg-- ev-- get,                      cfg-- ev-- put, cfg-- ev--          off - register to                      obtain event notification, collect                      events, send events and turn off                      event collectionSYNOPSIS            #include <config.h>                      int                      cfg-- ev-- create(char *qname, int          flags)                      int                      cfg-- ev-- off(char *qname)                      int                      cfg-- ev-- get(        char    *qname,        void        *sdp,        int          wait,        sdid-- t                  *sdidp          )                  int3                  cfg-- ev-- put(sdid-- t *sdidp)DESCRIPTION      These functions register to collect,                  send and receive configuration                  events.                 cfg-- ev-- create ( )                       is used to register to collect          events in the named event          notification queue qname. Its          behavior is modified                CFG-- EV-- PERM                       This flag indicates that the          named queue will not be          destroyed automatically on          process exit.                CFG-- EV-- EXISTERR                       This flag indicates that it is          not an error for a user to          attempt to create an event          notification queue that already          exists. If this flag is not          set, and the named queue does          exist, the errno EEXIST will be          returned.                    cfg-- ev-- off ( )                       unregisters event collection and          causes the named queue to be          deleted.          cfg-- ev-- get ( )                                 returns the appropriate sdid          within the address of the sdid-- t          for all events that are in the          named queue. If no events are          present then this routine will          either block or return without          setting sdidp according to          whether the wait argument is          TRUE (non-zero) or FALSE (zero),          respectively.             cfg-- ev-- put ( )                           may be used to send user-          specified events. User data may          be sent in the sdi-- user field of          the sdid-- t.RETURN VALUES  Upon success, the number of events                      collected or sent are returned by                      cfg-- ev-- get( ) or cfg--          ev-- put( ).                      cfg-- ev-- create ( ) and cfg--          ev-- off ( )                      return 0 on success or errno to                      indicate failure. Errors are                      indicated by a negative value. The                      absolute value of this will be an                      errno, as in intro(2).______________________________________

As has been shown, the storage manager independent configuration interface translator and method of the present invention herein disclosed first determines what sets or groups of storage devices are available for use and then determines what storage descriptors are in use in those particular sets. Since the storage descriptors are opaque, an accessor function is utilized to get inside of them. The opaque structures are then converted to a non-opaque format text which can be utilized by CLI and GUI tools. The present invention also provides a notification mechanism that presents information about devices which have changed while in use.

While there have been described above the principles of the present invention in conjunction with specific operating systems and drivers, it is to be clearly understood that the foregoing description is made only by way of example and not as a limitation to the scope of the invention. Particularly, it is recognized that the teachings of the foregoing disclosure will suggest other modifications to those persons skilled in the relevant art. Such modifications may involve other features which are already known per se and which may be used instead of or in addition to features already described herein. Although claims have been formulated in this application to particular combinations of features, it should be understood that the scope of the disclosure herein also includes any novel feature or any novel combination of features disclosed either explicitly or implicitly or any generalization or modification thereof which would be apparent to persons skilled in the relevant art, whether or not such relates to the same invention as presently claimed in any claim and whether or not it mitigates any or all of the same technical problems as confronted by the present invention. The applicants hereby reserve the right to formulate new claims to such features and/or combinations of such features during the prosecution of the present application or of any further application derived therefrom.

Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5363487 *Aug 29, 1989Nov 8, 1994Microsoft CorporationMethod and system for dynamic volume tracking in an installable file system
US5455934 *Mar 11, 1994Oct 3, 1995Eclipse Technologies, Inc.Fault tolerant hard disk array controller
US5511227 *Sep 30, 1993Apr 23, 1996Dell Usa, L.P.Method for configuring a composite drive for a disk drive array controller
US5530960 *Apr 6, 1994Jun 25, 1996Dell Usa, L.P.Disk drive controller accepting first commands for accessing composite drives and second commands for individual diagnostic drive control wherein commands are transparent to each other
US5553233 *Aug 4, 1995Sep 3, 1996Nec CorporationManagement apparatus for volume-medium correspondence information for use in dual file system
US5802364 *Apr 15, 1996Sep 1, 1998Sun Microsystems, Inc.Metadevice driver rename/exchange technique for a computer system incorporating a plurality of independent device drivers
US5809303 *Oct 18, 1995Sep 15, 1998Sun Microsystems, Inc.Device I/O monitoring mechanism for a computer operating system
Non-Patent Citations
Reference
1Baker, Steve, "UnixWare", UNIX Review, v11, n5, p66(7), May 1993.
2 *Baker, Steve, UnixWare , UNIX Review, v11, n5, p66(7), May 1993.
3Baker, Steven, "Journaling file systems: advanced network file systems offer journaling for fast recovery, greater integrity and reliability, and faster I/O. (Interoperability supplement to LAN Magazine)", LAN Magazine, v9, n10, pS59(9), Oct. 1994.
4 *Baker, Steven, Journaling file systems: advanced network file systems offer journaling for fast recovery, greater integrity and reliability, and faster I/O. (Interoperability supplement to LAN Magazine) , LAN Magazine, v9, n10, pS59(9), Oct. 1994.
5 *Computer Technology Review, vol. 12, No. 11, Sep. 1993, Los Angeles, CA, pp. 46 49, Beyond HSM: Data Management In The Native Environment .
6Computer Technology Review, vol. 12, No. 11, Sep. 1993, Los Angeles, CA, pp. 46-49, "Beyond HSM: Data Management In The Native Environment".
7 *Computer Technology Review, vol. 15, No. 11, Nov. 1995, Los Angeles, CA, pp. 50 52, Client/Server, GUI Software Simplifies RAID Management .
8Computer Technology Review, vol. 15, No. 11, Nov. 1995, Los Angeles, CA, pp. 50-52, "Client/Server, GUI Software Simplifies RAID Management".
9Drapeau et al., "RAID-II A High-Bandwidth Network File Server", IEEE, pp. 234-244, 1994.
10 *Drapeau et al., RAID II A High Bandwidth Network File Server , IEEE, pp. 234 244, 1994.
11 *IBM Technical Disclosure Bulletin, vol. 38, No. 5, May 1995, Armonk, NY, pp. 151 152, Supporting Removable Storage Media Which Has Multiple Partitions .
12IBM Technical Disclosure Bulletin, vol. 38, No. 5, May 1995, Armonk, NY, pp. 151-152, "Supporting Removable Storage Media Which Has Multiple Partitions".
13Jolitz, William Frederick; Jolitz, Lynne Greer, "Porting UNIX to the 386: the basic kernel", Dr. Dobb's Journal, v16, n11, p46(9), Nov. 1991.
14 *Jolitz, William Frederick; Jolitz, Lynne Greer, Porting UNIX to the 386: the basic kernel , Dr. Dobb s Journal, v16, n11, p46(9), Nov. 1991.
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7594075Oct 20, 2004Sep 22, 2009Seagate Technology LlcMetadata for a grid based data storage system
US7657705 *Sep 27, 2006Feb 2, 2010Lsi CorporationMethod and apparatus of a RAID configuration module
US7836101 *Jun 4, 2003Nov 16, 2010Thomson LicensingHeterogeneous disk storage management technique
Classifications
U.S. Classification719/321, 711/114
International ClassificationG06F3/06
Cooperative ClassificationG06F3/0601, G06F2003/0697
European ClassificationG06F3/06A
Legal Events
DateCodeEventDescription
Apr 7, 2011FPAYFee payment
Year of fee payment: 12
Apr 13, 2007FPAYFee payment
Year of fee payment: 8
May 28, 2003REMIMaintenance fee reminder mailed
May 6, 2003FPAYFee payment
Year of fee payment: 4
Sep 26, 1996ASAssignment
Owner name: SUN MICROSYSTEMS, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SENATOR, STEVEN T.;PASSMORE, DALE R.;GITTINS, ROBERT S.;REEL/FRAME:008201/0469
Effective date: 19960613