Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
  • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
  • G06F3/0601—Interfaces specially adapted for storage systems
  • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
  • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F15/00—Digital computers in general; Data processing equipment in general
  • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
  • G06F13/14—Handling requests for interconnection or transfer
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/606—Protecting data by securing the transmission between two devices or processes
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
  • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
  • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
  • G06F3/0601—Interfaces specially adapted for storage systems
  • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
  • G06F3/0608—Saving storage space on storage systems
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
  • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
  • G06F3/0601—Interfaces specially adapted for storage systems
  • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
  • G06F3/062—Securing storage systems
  • G06F3/0623—Securing storage systems in relation to content
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
  • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
  • G06F3/0601—Interfaces specially adapted for storage systems
  • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
  • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
• • G—PHYSICS
  • G11—INFORMATION STORAGE
  • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
  • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
  • G11B20/00007—Time or data compression or expansion
• • G—PHYSICS
  • G11—INFORMATION STORAGE
  • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
  • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
  • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
• • G—PHYSICS
  • G11—INFORMATION STORAGE
  • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
  • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
  • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
  • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
• • G—PHYSICS
  • G11—INFORMATION STORAGE
  • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
  • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
  • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
  • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
  • G11B20/00485—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier characterised by a specific kind of data which is encrypted and recorded on and/or reproduced from the record carrier
  • G11B20/00492—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier characterised by a specific kind of data which is encrypted and recorded on and/or reproduced from the record carrier wherein content or user data is encrypted

Definitions

• the present invention relates to storage managers that provide data storage services to software applications. More particularly, the invention concerns the provision of filtering functions such as encryption, compression and other data conversions as part of storage manager operations.
• a storage manager is a system that acts as an intermediary between a software application (such as a backup/restore program or a web server) and a data storage resource (such as a tape drive, a disk drive, a storage subsystem, etc.).
• the storage manager which could be integrated with the application program or implemented separately therefrom, provides an interface that accepts objects for storage and subsequently retrieves the objects upon request.
• Applications for which a storage manager has been used include the management of backup images of database installations, enterprise application data, individual workstations, web content, etc.
• Drawbacks of the first approach include:
• the storage manager vendor may charge customers extra to enable the compression and/or encryption algorithms that are built in. • If a built-in algorithm is found to have a security flaw or a crippling bug, a customer cannot immediately swap in a different off-the-shelf algorithm to avoid exposure to the risk.
• a vendor may not implement a particular compression or encryption algorithm that a customer desires.
• Drawbacks of the second approach include: • The storage manager programming hook places a burden on the customer to reimplement much of the functionality the storage manager otherwise provides.
• the user must typically write a program that can accept objects for storage, track the location of these objects, write and read them to/from physical storage devices, and retrieve them upon request based on whatever query protocol the storage manager requires, as well as write in the desired compression and/or encryption algorithms.
• the storage manager essentially delegates all work to the user and does not provide any functionality of its own.
• the storage manager mostly acts as a hollow shell or "stub" that forwards all storage and retrieval requests to the user-written external program for handling.
• the storage manager itself merely assembles and disassembles buffers of information that pass between it and the application that is calling it, and provides stubs for the interface APIs (Application Programming Interfaces) but delegates most of the work to the user's program.
• a customer who uses the programming hook but does not sufficiently test and debug their external program may find that their data has been corrupted by their own custom program, or that bugs in the program prevent the retrieval of storage objects at a critical time, such as when they need them to restore a down system. • If the event described in the preceding paragraph occurs, the storage manager vendor may find itself exposed to liability for the customer's own programming mistakes.
• this capability would be useful if backup data was generated by a first system in a first character format (e.g., a mainframe computer using EBCDIC character) and the data needed to be restored to a second system that used a second character format (e.g., a workstation using ASCII character encoding).
• a first character format e.g., a mainframe computer using EBCDIC character
• a second character format e.g., a workstation using ASCII character encoding
• Another area where storage manager filtering could be used is the generation of audit trails. Such a filter could be used to inspect the data being stored or retrieved and generate audit information for management purposes.
• a storage manager that manages client data on a data storage resource has the ability to utilize many different types of data stream filters that are neither built into the storage manager nor require a custom programming effort.
• a storage manager user may readily implement filtering by simply identifying a data stream filter the user wishes the storage manager to use for filtering the user's data.
• the filter can be an off-the-shelf program that is not part of the storage manager and which does not require client application or storage manager domain knowledge (e.g., knowledge of protocols or data types used by the client application or the storage manager).
• the storage manager invokes the identified filter as part of a requested data stream operation and receives a data stream from a data stream source.
• the data stream is provided to the filter, which filters the data stream.
• the storage manager receives the data stream from the filter and sends it to a data stream destination.
• the filter identification may be received as one of an attribute of a storage manager transaction request, a storage resource, an application, a host, a user, a storage object category, etc.
• the filtering may or may not result in a transformation of the data stream. If the filter does transform the data stream, it may be implemented as part of a filter pair comprising a write filter that performs a transformation on the data stream and a read filter that may or may not reverse the transformation. Such transformation may include compression/decompression filtering, encryption/decryption filtering, character set conversion filtering, etc. If the filter does not transform the data stream, it may instead be designed to generate information about the data stream, such as an audit trail.
• the filter may be invoked in its own execution context and the data stream may be exchanged with the filter via an interprocess communication mechanism.
• This mechanism may comprise a first and second pipes, one for providing the data stream to the filter and the other for receiving the filtered data stream from the filter.
• the filter may be invoked with a filter argument that is passed if the filter is adapted to process the argument, or suppressed otherwise.
• the filter may be an encryption or decryption filter and the filter argument may pertain to the identification of an encryption key.
• the storage manager is adapted to manage client data on a data storage resource with data stream filtering as a service on behalf of a remote client.
• the storage manager receives either a copy of a client-selected filter or an identification of such a filter from the remote client or a location specified by the remote client, such as a trusted authority.
• a storage manager is adapted to a utilize plug-in that is not necessarily a data stream filter. Such a plug-in may be a custom program that has domain knowledge of the client application data format or the storage manager, such that it is not a true data stream filter.
• Fig. 1 is a functional block diagram showing an exemplary storage manager, a client application and a data storage resource;
• Fig. 2 is a functional block diagram showing one possible implementation of the components shown in Fig. 1;
• Fig. 3 is a functional block diagram showing exemplary details of the storage manager of Fig. 1;
• Fig. 4 is a functional block diagram shown an exemplary mechanism for interprocess communication between the storage manager of Fig. 3 and a filter;
• Fig. 5 is a flow diagram showing exemplary steps that may be implemented by the storage manager of Fig. 1 to perform data stream filtering;
• Fig. 6 is a functional block diagram showing the storage manager of Fig. 1 in combination with a pair of read and write filters;
• Fig. 7 is a flow diagram showing exemplary steps that may be implemented by a storage manager parent process to invoke a filter
• Fig. 8 is a flow diagram showing exemplary steps that may be implemented by a filter client process created by a storage manager parent process
• Fig. 9 is a functional block diagram showing an exemplary implementation of the storage manager of Fig. 1 in a remote storage manager service environment;
• Fig. 10 is a functional block diagram showing exemplary data processing hardware that may be used to provide a system for implementing a software version of the storage manager of Fig. 1;
• Fig. 11 is a diagrammatic representation of exemplary storage media that may be used in a computer program product implementation of the storage manager of Fig. 1.
• FIG. 1 illustrates a storage manager 2 that stores and retrieves data generated by a client application 4.
• the storage manager 2 receives a stream of data objects (data stream) from the application 4 and stores the objects in a data storage resource 6, typically (but not necessarily) for archival purposes.
• the storage manager 2 retrieves previously stored objects from the data storage resource 6 and returns them to the application 4.
• the storage manager logic may be implemented in software, firmware, hardware, or any combination thereof.
• the application 4 may represent any software application that desires to have its data placed in the data storage resource 6.
• the data storage resource 6 may be implemented as any physical storage device or system, including one or more tape drives, disk drives, storage subsystems, etc.
• a database system 8 represents one possible environment in which the components of Fig. 1 could be adapted for use.
• the storage manager 2 is exemplified by a tape and disk storage manager 10
• the application 4 is exemplified by a database backup/restore system 12
• the data storage resource 6 is exemplified by a set of tape storage volumes 14 operable in a tape drive system (not shown) and disk storage volumes 15.
• the backup/restore system 12 provides data backup and restore services on behalf of a database server 16 whose storage space and logical logs 18 need to be periodically backed up and restored.
• the backup/restore system 12 could be implemented in the environment of Fig.
• the database server 16 may communicate backup and restore requests to the backup/restore system 12 via an Archive API (Application
• the backup/restore system 12 would invoke the storage manager 10 to implement storage and retrieval operations via a protocol such as XBSA (X/Open Backup Services API).
• XBSA X/Open Backup Services API
• the storage manager 10 may be implemented (with appropriate modifications to support filtering as described herein) using a product such as the IBM ® Informix ® Storage Manager (ISM).
• the storage manager 10 manages the tape storage volumes 14 and disk storage volumes 15.
• the storage manager 10 also maintains inside the disk storage volumes 15 a catalog 20 of backup and restore operations that correlates stored data objects with the corresponding tape storage volumes 14 and disk storage volumes 15.
• Among the functions of the storage manager 10 are writing and reading data on the actual tapes and disks, keeping track of what data is on which tape or disk, and assigning the data to categories.
• a data backup operation may be initiated by an administrator of the database server 16 issuing a backup request to the backup/restore system 12.
• the backup/restore system 12 determines what data needs to be backed up and connects to the storage manager 10.
• the backup/restore system 12 then retrieves the appropriate data from the storage space and logical logs 18, builds a list of backup objects, and passes it to the storage manager 10.
• the storage manager 10 creates a save set from the data object list and writes the save set (comprising one or more data objects) to the proper tape storage volumes 14 and/or disk storage volumes 15.
• the storage manager 10 then enters a record of the save sets and the storage volumes in the catalog 20.
• the storage manager 10 uses the catalog 20 to track the save sets and the volumes on which they are backed up.
• a data restore operation may be initiated by an administrator of the database server 16 issuing a restore request to the backup/restore system 12.
• the backup/restore system 12 determines what data needs to be restored and connects to the storage manager 10.
• the storage manager 10 searches the catalog 20 for the specific restore objects requested by the backup/restore system 12 and maps each restore object to its offset in the save set.
• the backup/restore system 12 then retrieves the data from the storage manager and passes it to the database server 16, object by object.
• the database server 16 writes the data to the proper location(s) in the storage space and logical logs 18.
• a storage manager it is sometimes desirable for a storage manager to filter data being stored in or retrieved from a data storage resource.
• Conventional storage managers offer limited filtering options, such as compression/decompression and encryption/decryption.
• filters are either embedded in the storage manager logic, and are thus difficult to modify or update, or a complex programming effort is required to create and implement such filters using a programming hook.
• the storage manager 2 improves upon this situation by providing a mechanism whereby a user can easily and straightforwardly plug in off-the-shelf compression, encryption, or other data conversion programs that can be applied to data being written to or read from the data storage resource 6.
• Fig. 3 illustrates an exemplary implementation of the storage manager 2 that may be used to implement this functionality.
• the storage manager 2 implements a filter invocation subsystem 30 that is responsible for invoking a filter 32 that may be specified from a group of filters 32 l s 32 2 . . . 32 n .
• These filters are not part of the storage manager 2. Instead, they are standalone programs (or libraries) residing in a data processing system that will typically also implement the storage manager (albeit in a separate execution context). Alternatively, the storage manager 2 and the filter 32 could execute on separate systems.
• a filter identification interface 34 allows a user to specify a filter 32 to be used as part of a requested data stream operation.
• the interface 34 may be implemented to support local or remote access to the storage manager 2, such as via a command line or graphical user interface operated by a user or administrator of the storage manager.
• a filter identification store 36 such as a storage file, a memory, etc., may be used to retain the filter identification in the storage manager 2. As described in more detail below, this supports the ability to identify a filter 32 as an object attribute, such as an attribute of the storage resource 6 (see Fig. 1), an application, a host, a user, or a data object category. Because other attributes for such objects are conventionally maintained by the storage manager 2 (e.g., data resource attributes) the addition of a filter attribute may be readily implemented. In this way, different filters 32 can be associated with different storage resources 6 (see Fig. 1), applications, hosts, users or storage object categories. Without this capability, a user or application would have to identify a filter as a parameter of each data stream command.
• the data storage manager 2 further includes a data stream receiver 38 and a data stream sender 40, as well as a filter writer 42 and a filter reader 44.
• a first conventional communication interface 46 is also provided for communicating with the application 4 (see Fig. 1) (e.g., implementing the XBSA protocol) and a second conventional communication interface 48 is provided for communicating with the data storage resource 6 (see Fig. 1) ( e -g- > implementing a storage device-specific protocol).
• Fig. 4 The arrangement of the data stream receiver 38, the data stream sender 40, the filter writer 42 and the filter reader 44 is shown in Fig. 4, as is the relationship between the data stream writer and the data stream reader relative to a filter 32.
• the operation of the storage manager 2, including the actions of the foregoing components, will now be described with additional reference to the flow diagram of Fig. 5.
• step 50 of Fig. 5 the ability of the storage manager 2 to utilize the filter 32 begins with a user identifying the filter to the storage manager via the filter identification interface 34.
• step 52 of Fig. 5 the storage manager 2 stores the filter identification in the filter identification store 36. Either subsequent to or contemporaneously with the filter identification, the storage manager 2 will be requested to perform a data stream operation, such as a backup or restore.
• the filter invocation subsystem 30 consults the filter identification store 36 and then invokes the filter 32 identified therein.
• the data stream receiver 38 receives a data stream from a data stream source. For some operations (e.g., data backup) the data stream source will be the application 4 (see Fig. 1). For other operations (e.g., data restore) the data stream source will be the data storage resource 6 (see Fig. 1).
• the data stream receiver 38 passes the incoming data stream to the filter writer 42. The function of the filter writer 42 is to provide the data stream to the identified filter 32 for filtering.
• the filter writer 42 will use an appropriate inter-process communication (IPC) mechanism, such as a pair of pipes Pl and P2 (see Fig. 4), to communicate with the filter.
• IPC inter-process communication
• Other IPC mechanisms such as sockets (e.g., if the filter 32 runs on a separate data processing system), could also be used.
• the filter reader 44 receives the filtered data stream back from the filter 32 that performed the filtering. It passes the filtered data stream to the data stream sender 40 in step 62 of Fig. 5, which sends the data stream to a data stream destination.
• the data stream destination will be the data storage resource 6 (see Fig. 1).
• data restore the data stream destination will be the application 4 (see Fig. 1).
• the filter program that comprises the filter 32 will not require any awareness of the protocols or data types used by the storage manager 2 or the application 4 (hereinafter referred to as "domain knowledge"), but need only read from stdin (standard input) and write to stdout (standard output).
• domain knowledge Such programs are true “filters” that are capable of processing raw data streams according to the standard definition of "filter” that has been well-known since the advent of the Unix operating system.
• the Unix "compress” and “uncompress” programs are just two of many examples of off-the-shelf programs that support this type of operation.
• Users may also specify a filter 32 that implements other desired data transformations, such as encryption and decryption or conversion between different character sets or code pages, conversion between English units and metric, etc.
• a non-data transforming filter 32 could also be specified, such as a filter 32 that performs a task such as auditing.
• a filter could copy part of a user's data and the current username to a separate log that enables later identification of the users and the data they have accessed.
• such a filter could inspect a data stream being processed by the storage manager 2 and create log information about the transaction.
• many filter programs will be off-the-shelf software, custom filter programs may also be created.
• Such filter programs may be true data stream filters in the Unix sense, or they may be more in the nature of plug-ins that require domain knowledge of the storage manager's protocols or the application's data types or formats, or can accept or require arguments other than just an input stream.
• some filter programs may be called with arguments.
• One such argument would be a unique ID for an object being stored or retrieved (Object ID).
• the filter program could choose to ignore this argument or it could use the argument as it sees fit.
• This capability would be useful for encryption filters, because a customer may have a policy that requires data to be encrypted with more than one key. In such a case, the object ID can be used to select the key to encrypt (write filter) or decrypt (read filter) the object in question.
• key id object id MOD n).
• an encryption filter might hard-code a single key that it always uses (but this makes securing the filter itself as important as securing encryption keys in general).
• Write filters are applied to data that the storage manager 2 will write to the data storage resource 6.
• the data that a user has asked to be written is passed to the write filter as input, then the output of the write filter is written to physical storage.
• Read filters are applied to data that the storage manager 2 will read from the data storage resource 6. The data is read from physical storage and passed to the read filter as input, then the output of the read filter is returned to the user who requested retrieval of this data.
• two filters 32 may be defined as pair: a write filter that transforms data in one direction (e.g. Unix "compress"), and a read filter that reverses the original transformation (e.g. Unix "uncompress").
• An example of such filter pairing is shown in Fig. 6, which illustrates a write filter 32w paired with a read filter 32 R .
• a filter 32 which simply passes data through unchanged may also be defined.
• a filter 32 may be defined as an attribute of a physical storage device (e.g. representing part of the data storage resource 6). This is convenient because in many storage managers the attributes of physical storage devices must be described before they can be used to store and retrieve data. Such attributes may include (1) the path to the device, (2) whether it is a disk or tape device, and (3) the maximum number of bytes to store in the device.
• the storage manager 2 may implement two new device attributes; namely, a read filter and writer filter. These attributes may be specified as flags on a device definition command, such as the following:
• This statement which may be used to define a physical storage device to the storage manager 10, identifies the device and various attributes thereof, including the -Fr flag which is followed by the path to a read filter program to use for this device and the -Fw flag which is followed by the path to a write filter program.
• the statement begins with the identifier "sm” to signify the storage manager.
• the "p” flag signifies a storage device path specification.
• the /diskl/ids/logbu” field identifies the actual path to the storage device.
• the read filter program identified by the -Fr flag is shown to be the Unix "uncompress” program and the write filter program identified by the -Fw flag is shown to be the Unix "compress” program. Both programs are normally located in the /usr/bin directory of a Unix file system.
• the storage manager 2 When the storage manager 2 receives the foregoing command, it can store the device attributes in a device attribute file and/or in memory. The portion of this file or memory that holds the read and write filter attributes may represent the filter identification store 36 of Fig. 3.
• the filter identification store 36 may thus be consulted by the filter invocation subsystem 30 during storage manager operations to determine what filter(s) to apply to data being written to or read from a particular physical device of the data storage resource 6.
• filter specifications are not limited to the physical device level. They could also be specified at different granularities, such as virtual device level, application level, host level, etc. Filters 32 may also be specified for different categories of storage objects, such as log files, data files, etc. Filters 32 may likewise be specified for different users or groups, or according to any other categorization scheme. Alternatively, if desired, filters 32 could be specified as a parameter of a data store or retrieve command each time the storage manager 2 is invoked by the application 4.
• a technique may be needed to handle filters 32 that do support this functionality.
• a filter 32 would be capable of either using or ignoring this argument.
• many off- the-shelf filters are required to read from stdin and write to stdout, and may complain that they do not recognize the argument.
• One way to solve this problem is to write a very small wrapper script around the off-the-shelf filter component in order to process the argument.
• other off-the-shelf filter programs such as the Unix "compress” and "uncompress” programs, one may write a wrapper that ignores arguments and simply passes data to the program.
• wrapper scripts could be made executable and defined as filters 32 to the storage manager 2 rather than defining the corresponding off-the- shelf filter programs directly to the storage manager.
• Another approach for handling filter programs that do not handle filter arguments would be to define a flag that indicates to the filter invocation subsystem 30 whether any arguments should be passed to the filters. If disabled for a given filter definition, the filter invocation subsystem 30 would not pass any argument to the filter 32, thereby enabling pure off-the-shelf filters that do not recognize or need the extra argument (such as a compress- uncompress pair) to be used without any wrapper script.
• the -Fr noarg flag indicates this is a read filter that should not be passed any arguments
• the -Fw noarg flag indicates this is a write filter that should not be passed any arguments.
• the -Fr flag indicates a read filter and the -Fr arg flag supplies a string of arguments to be passed to the read filter whenever it is invoked.
• the -Fw flag indicates a write filter and the -Fw arg flag supplies a string of arguments to be passed to the write filter whenever it is invoked.
• a process in a Unix version of the storage manager 2 that has data to write to physical storage can first pass it through a write filter as follows:
• the child process executes the filter and services in_pipe and out_pipe as follows:
• the parent storage manager process writes unprocessed data to the input end of in_pipe (Pl), which the child filter process reads from the output end of in_pipe (because a filter always reads from stdin, which the child has redirected to be the output end of in_pipe).
• the child filter process writes the processed results to the input end of out_pipe (P2) (because a filter always writes to stdout, which the child has redirected to be the input end of out_pipe).
• the parent storage manager process retrieves the processed data from the output end of out_pipe and writes it to physical storage.
• Read processing can be performed in inverse fashion.
• a process in a Unix version of the storage manager 2 that has to read data from physical storage can first pass it through a read filter as follows:
• the child process executes the filter and services in_pipe and out_pipe as follows:
• the parent storage manager process reads unprocessed data from physical storage and writes it to the input end of in_pipe (Pl), which the child filter process reads from the output end of in_pipe (because a filter always reads from stdin, which the child has redirected to be the output end of in_pipe).
• the child filter process writes the processed results to the input end of out_pipe (P2) (because a filter always writes to stdout, which the child has redirected to be the input end of out_pipe).
• the parent storage manager process retrieves the processed data from the output end of out_pipe.
• Figs. 7 and 8 are flow diagrams respectively representing the operations of the storage manager parent process and the child filter process when the foregoing actions are performed.
• step 70 represents the parent process creating in_pipe (Pl) and out_pipe (P2).
• step 72 of Fig. 7 represents the parent process forking the child process to execute the child filter.
• Step 74 of Fig. 7 represents the parent process writing data to the input end of in_pipe.
• Step 76 of Fig. 7 represents the parent process reading data from the output end of out_pipe.
• step 78 represents the child process closing stdin and replacing it with the output end of in_pipe (Pl).
• Step 80 of Fig. 8 represents the child process closing stdout and replacing it with the input end of out_pipe (P2).
• Step 82 of Fig. 8 represents the child process executing the filter command.
• Step 84 of Fig. 8 represents the child process exiting when the end of the input stream is reached.
• a further exemplary implementation of the storage manager 2 is shown in which the storage manager operates at a server site 90 in order to provide storage manager services on behalf of a remote client 92 via a network 94.
• the application 4 and the data storage resource 6 may also be located at the server site 90. Alternatively, those components could be located off premises at other locations.
• the client 92 could maintain a filter 96 that it provides to the storage manager 2 for use in filtering the client's data (e.g., via a filter receiving interface 97). The storage manager 2 would thus implement a copy of the filter 96 locally at the server site 90.
• the client 92 could maintain the sole copy of the filter 96 and simply identify it to the storage manager 2 (e.g., via the filter identification interface 34). In that case, the storage manager 2 could invoke the filter 96 using a remote procedure call and pass data to the filter across the network 94, preferably using a secure connection (e.g., SSL (Secure Socket Layer)). If the server site 90 had a policy that prohibited the use of untrusted third party filters, the client 92 could specify a filter (to the storage manager 2) that resides in a repository 98 maintained by a trusted filter authority.
• SSL Secure Socket Layer
• Users are not limited to the compression, encryption, or other filters provided by a storage manager vendor.
• a user can quickly swap out a filter that is found to have a security flaw or crippling bug and swap in another off-the-shelf component that provides similar functionality, without having to wait for the storage manager vendor to issue a patch release.
• FIG. 10 illustrates an exemplary hardware environment 100 that may be used if the storage manager 2 is implemented as software.
• the hardware environment 100 includes a CPU or other data processing resource 102 and a main memory 104 that provide a data processing core, a graphics card 106 for generating visual output information to a display monitor 107, a peripheral storage device 108, other peripheral devices 110, and a bus infrastructure 112 interconnecting the foregoing elements.
• the storage manager 2 may be loaded in the main memory 104.
• the application 4 (see Fig. 1) could also be loaded in the memory 104 if it runs on the same hardware platform.
• the storage device 108 may be used as persistent storage for the filter identification store 36. A copy of the filter information could also be maintained in the memory 104.
• Other data sources may be accessed through I/O (Input/Output) resources provided by the peripheral devices 110, which may include a USB bus controller, a SCSI disk controller, and a network interface card.
• the monitor 107 may be used to present administrative information.
• exemplary data storage media for storing the programming logic are shown by reference numeral 200 in Fig. 11.
• the media 200 are shown as being portable optical storage disks of the type that are conventionally used for commercial software sales, such as compact disk-read only memory (CD-ROM) disks, compact disk-read/write (CD- R/W) disks, and digital versatile disks (DVDs).
• CD-ROM compact disk-read only memory
• CD- R/W compact disk-read/write
• DVDs digital versatile disks
• Such media can store the programming logic of the invention, either alone or in conjunction with another software product that incorporates the required functionality.
• the programming logic could also be provided by portable magnetic media (such as floppy disks, flash memory sticks, etc.), or magnetic media combined with drive systems (e.g.
• disk drives or media incorporated in data processing platforms, such as random access memory (RAM), read-only memory (ROM) or other semiconductor or solid state memory. More broadly, the media could comprise any electronic, magnetic, optical, electromagnetic, infrared, semiconductor system or apparatus or device, transmission or propagation medium (such as a network) or signal, or other entity that can contain, store, communicate, propagate or transport the programming logic for use by or in connection with a data processing system, computer or other instruction execution system, apparatus or device.
• RAM random access memory
• ROM read-only memory
• the media could comprise any electronic, magnetic, optical, electromagnetic, infrared, semiconductor system or apparatus or device, transmission or propagation medium (such as a network) or signal, or other entity that can contain, store, communicate, propagate or transport the programming logic for use by or in connection with a data processing system, computer or other instruction execution system, apparatus or device.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Human Computer Interaction (AREA)
• Software Systems (AREA)
• Computer Hardware Design (AREA)
• Health & Medical Sciences (AREA)
• Bioethics (AREA)
• General Health & Medical Sciences (AREA)
• Computer Security & Cryptography (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Storage Device Security (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=39361461

Family Applications (1)

Country Status (7)

Families Citing this family (24)

Family Cites Families (40)

• 2007
  • 2007-03-26 US US11/690,943 patent/US7962638B2/en not_active Expired - Fee Related
• 2008
  • 2008-03-17 JP JP2010500199A patent/JP5571544B2/ja active Active
  • 2008-03-17 EP EP08717881A patent/EP2145247A1/en not_active Withdrawn
  • 2008-03-17 CN CN200880008566.1A patent/CN101646995B/zh active Active
  • 2008-03-17 CA CA2669896A patent/CA2669896C/en active Active
  • 2008-03-17 KR KR1020097012625A patent/KR20090106476A/ko active IP Right Grant
  • 2008-03-17 WO PCT/EP2008/053144 patent/WO2008116771A1/en active Application Filing
• 2011
  • 2011-02-23 US US13/033,353 patent/US9152345B2/en active Active

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events