The present invention relates to computing device control of a storage device, and more particularly control using read and write operations.
Computer storage is the holding of data in an electromagnetic form for access by a computer processor. The storage may be divided to primary storage, such as random access memory (RAM), and secondary storage such as hard disks, also referred to as bulk storage. Secondary storage may be further divided into internal storage, such as, in one example, a hard drive that is shipped with a PC, and external storage, such as a removable hard drive that connects to the PC through the Universal Serial Bus (USB) interface. The PC, also called host PC, or another host device with a computer processor, controls a particular storage device by a software program called a device driver. A device driver essentially converts the more general input/output instructions of the operating system to messages that the device can understand.
A common standard for implementing bulk storage devices is a “block device” model. Block devices manage their storage in fixed sized blocks, for example blocks of 512 bytes. Each block is assigned a Logical Block Address (LBA), which can be addressed by the device driver. A software layer known as a file system, which is a part of the operating system that resides on the host PC or host device, performs the operation of managing files using storage blocks.
In order to manage files on a block device, a file system uses READ BLOCK and WRITE BLOCK commands, which essentially enable retrieving blocks of data from the storage device and writing blocks of data to the storage device. Usually one of the parameters of these commands is the LBA of the particular block of interest. The file system maintains structured management data in one or more storage blocks which assists in performing file based operations, such as creating a file, retrieving data from a file, etc. An example of such a structure is the FAT (File Allocation Table) file system. The FAT table keeps track of which LBA's were used and for what purpose. For example, a FAT table may contain the ordered series of LBA's used to store a certain file. Since during the operation of a storage device, this data may go through many changes, some operating systems cache the data to the RAM in order to gain speed, and then write the changed data back to the storage at appropriate occasions.
Other commands sent to block devices are CONTROL commands, enabling the host computer to perform control operations on the storage device based on the parameters of the command. Examples are formatting the storage device, initiating a self-test diagnostic operation, changing internal device parameters, and vendor specific commands.
Since CONTROL operations, if used improperly, might be harmful to the integrity of the storage device, popular operating systems such as the Windows and Mac OS families place certain restrictions on the usage of CONTROL commands. For example the CONTROL command in Windows “DeviceIoControl( )” is restricted to users that have administrative permissions only. The underlying logic of this approach is that, for normal uses, the READ and WRITE commands suffice, whereas CONTROL commands are needed only in setup and configuration scenarios. In corporations and enterprises where an IT administrative team handles configuration of many PCs, this reduces the risk of inexpert computer users causing damage to the storage device or a loss of data by trying to do configuration and setup operations themselves.
In the past few years a new type of storage device has emerged, collectively known as USB flash drive or keychain storage. This is an external storage device based on non-volatile flash technology and connected to the host PC or host device using the USB interface. Examples are Sony MicroVault, Dell Memory Key, and M-Systems DiskOnKey (www.diskonkey.com). These storage devices usually have some computational power and therefore may perform other tasks other than just serving as a storage device. Examples are MicroVault AutoLogin which automatically fills website user IDs and passwords, and Password Lock, enabling password protection of any portion of the storage device's contents. Another example is DiskOnkey MyKey—a graphic user interface that lets users designate frequently used files for quick and easy transfer, choose language preferences, and set audio or visual indications for new data. Still another example is the ability to upgrade the software that is to run on the storage device, as shown by Cyberkey's “future-proof technology” (www.cyberkeycorp.com). Other and more complex applications are feasible.
The common feature of the above-mentioned applications and others is that they are executed both on the host PC and on the storage device itself using its own controller. In order to function properly, the program running on the host PC and the program running on the storage device must interact by transferring information between each other.
Since these storage devices operate under the block device model, the common method to create a communications channel is by using a CONTROL command. However, this interface is available only to host devices configured as administrative users, which means that in order to run the aforementioned storage device applications, users must be granted administrative permissions. While technologically feasible, many organizations will not enable administrative permissions to all employees or other users due to the risk of damage users might cause to other components of their computers.
There is clearly an unmet need for enabling users to run applications on the storage device while permissions in the host device are set at a non-administrative level.
The above-mentioned problem is addressed by the various embodiments of the present invention, which will be understood by reading the following specification.
According to the present invention, the means to communicate between a PC Application executing in the host computer and the Storage Application executing inside a storage device is achieved through the use of one or more files in the storage device, to which both applications have access.
The PC Application accesses the file or files using the WRITE BLOCK and READ BLOCK commands and access to the file or files does not necessitate administrative permissions. The content written to such a file includes commands, data and parameters addressed to the Storage Application to execute or process. In a similar manner, when the host issues a READ command to the file, the storage device returns a response from the Storage Application by reading from such a file.
The foregoing has outlined rather broadly the features and technical advantages of embodiments of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of embodiments of the invention will be described hereinafter, which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and specific embodiments disclosed may be readily utilized as a basis for modifying or designing other structures or processes for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims, and such equivalent structures fall within the scope of the appended claims.
For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
Corresponding numerals and symbols in the different figures generally refer to corresponding parts unless otherwise indicated. The figures are drawn to clearly illustrate the relevant aspects of the preferred embodiments and are not necessarily drawn to scale.
The structure, making and using of the presently preferred embodiments of the invention are discussed in detail below. It should be appreciated, however, that the present invention provides many applicable inventive concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed are merely illustrative of specific ways to make and use the invention, and do not limit the scope of the invention or the appended claims
In the following description of exemplary embodiments of the invention, reference is made to the drawings that illustrate specific exemplary embodiments in which the invention may be practiced. Those skilled in the art will appreciate that other embodiments may be utilized without departing from the spirit of the present invention; therefore the following detailed description of the invention should not be taken in a limiting sense. In various embodiments, there may be none, one, or more than one of the following described parts.
The Client Application Channel Layer 101 is software executing in the host PC or device and used by a PC Application to send and retrieve commands, data and parameters to and from the Storage Application. The Client Application Channel Layer 101 performs operations such as: accepting requests from the PC Application, converting the requests into a sequence of one or more READ BLOCK and/or one or more WRITE BLOCK commands, sending responses to the PC Application, housekeeping, and management of the communication process and the like.
The Server Application Channel Layer 102 is software executing in the storage device and used to identify READ BLOCK and/or WRITE BLOCK commands addressed to a certain file or plurality of files. When such a command is identified, the Server Application Channel Layer 102 processes the request by performing one or more operations such as forwarding the command to the Storage Application, retrieving or storing some data, returning some values to the Client Application Channel Layer 101 or the like operations. In some embodiments, the Client Application Channel Layer 101 or parts of the Client Application Channel Layer 101 are integrated into the PC Application, this invention is not so limited.
In step 202, in those cases that the Communication File could not be located, the Server Application Channel Layer creates it. In some embodiments this may be implemented by creating and placing a new file in the root directory or in a sub-directory of a FAT file system. In some embodiments, the creation process will also allocate one or more storage blocks for the Communication File. In some embodiments, the creation process will also fill some storage blocks with data. In step 203, the Server Application Channel Layer records one or more LBA's that were allocated for the Communication File.
In step 302, the Client Application Channel Layer sends the request to the storage device by writing into the Communication File. This operation engages the file system and the operating system running in the host PC to generate a series of none, one or more WRITE_BLOCK commands and/or none, one or more READ_BLOCK commands eventually requesting the storage device to place the sent data in LBA's that are allocated for the Communication File. In some embodiments, the Client Application Channel Layer opens a file for each request and closes it once the request is completed. In other embodiments the Client Application Channel Layer opens the file once at the beginning of the session and closes it upon completion. Yet in other embodiments, a combination of the above is implemented, the invention is not so limited.
In step 303 the Server Application Channel Layer intercepts the attempt to write data blocks into the LBA's of the Communication File or read blocks from them. In step 304 the Server Application Channel Layer optionally processes or partially processes the request and forwards it to the Storage Application.
In some embodiments the Communication File is limited in size beyond its initial size while in other embodiments it is allowed. In some embodiments, if the file is expanded, the blocks beyond the initial size are not recorded by the Server Application Channel Layer in order to enable their capturing, while in other embodiments they are recorded. In some embodiments the Communication File allocated storage blocks may be modified as result of the WRITE BLOCK operation and in other embodiments they are not modified. It may be appreciated by those skilled in the art that other embodiments, or combinations of such embodiments may exist without departing from the spirit of the present invention.
In step 402 the Client Application Channel Layer sends the request to the storage device by reading from the Communication File. This operation engages the file system and the operating system running in the host PC to generate a series of none, one or more READ_BLOCK commands eventually requesting the storage device to retrieve the data that is stored in LBA's that are allocated for the Communication File. In some embodiments the Client Application Channel Layer opens a file for each request and closes it once the request is completed. In other embodiments the Client Application Channel Layer opens the file once at the beginning of the session and closes it upon completion. Yet in other embodiments a combination of the above is implemented, the invention is not so limited.
In step 403, the Server Application Channel Layer captures the attempt to read data blocks from the LBA's of the Communication File. In step 404 the Server Application Channel Layer optionally processes or partially processes the read request and forwards it to the Storage Application to retrieve data or a response. In step 405 the retrieved data and/or response is sent back to the Client Application Channel Layer to complete the Communication File read operation.
In some embodiments, parts of the Client Application Channel Layer are integrated with the PC Application, enabling operations such as initializing, and/or writing to the Communication and/or reading from the Communications File or the like to be implemented in the integrated PC Application.
In other embodiments, a plurality of Communication Files is used for various purposes; for example one file may be used by the Client Application Channel Layer to execute write operations while a second file might be used to execute read operations.
In yet other embodiments, the storage device may enable more than one Storage Application, and the Communication File is used to enable access to all. In another embodiment a plurality of Communication Files are used, one or more for each of the Storage Applications.
In still further embodiments, the data being written by the Client Application Channel Layer is actually written into the LBA's of the file and the Server Application Channel Layer is triggered to read the LBA's.
In still further embodiments, the data being read by the Client Application Channel Layer is actually read from the LBA's of the communication file by Server Application Channel Layer Server. The invention is not so limited.
Although embodiments of the present invention and their advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims. For example, it will be readily understood by those skilled in the art that many of the features, functions, processes, and materials described herein may be varied while remaining within the scope of the present invention. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure of the present invention, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed, that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present invention. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.
This application claims the benefit of U.S. Provisional Application No. 60/490,439, filed on Jul. 28, 2003, entitled System and Method for Controlling a Storage Device, which application is hereby incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
60490439 | Jul 2003 | US |