Online data conversion technique using a sliding window

An embodiment of the invention provides an apparatus and method for online data conversion. The apparatus and method are configured to read data that is overlapped by a window in a first position in a volume, convert the data into a converted text, write the converted text into the volume, and slide the window to a second position in the volume.

TECHNICAL FIELD

Embodiments of the invention relate generally to an online data conversion technique.

BACKGROUND

Encryption is the conversion of data into an encrypted form that is known as “cipher text” which is not easily understood by unauthorized personnel. Decryption is the conversion of the cipher text back into the original form of the data (i.e., plain text). Current file and volume encryption technology permits the storage of data into backup media (e.g., disk, tape or memory device) in the encrypted form so that the data is not comprehensible to unauthorized personnel. The encryption can be applied to individual files, or applied to the entire data in a volume that is formed by a physical storage disk. One example of a file and volume encryption technology is the HP-UX Encrypted Volume and File System (EVFS) which is commercially available in various products from Hewlett-Packard Company.

One limitation of current technology is that applications are required to be shut down and are not able to access volume data when the volume is being configured for storing the cipher text (encrypted text), when the data encryption key is being changed (re-keying), or when the volume is being reconverted for storing the plain text (decrypted text). When the volume is being configured for encryption, the following steps are required: (1) the application(s) that are using the volume are shut down, (2) the plain text data in the volume are backed up on a backup media (e.g., tape or disk), (3) the volume space is extended to create space for the encryption metadata, (4) the volume is initialized by writing the encryption metadata at the beginning of the volume, (5) the volume is brought online (enabled for encryption), (6) the plain text data are restored from the backup media to the volume as encrypted text, and (7) the applications(s) that were previously shut down are re-started. Similar steps above (e.g., backing up the volume data and restoring the volume data) are performed if the volume data is re-keyed (i.e., re-encrypted) or is converted from cipher text to plain text (decrypted text).

In computing environments with very large volumes (e.g., sizes of terabytes or petabytes), applications will need to be turned off for a significant amount of time (e.g., many hours or days) until the entire volume data is converted from plain text to cipher text. Furthermore, certain customer environments (e.g., financial service industry entities such as banks) have security policies that often require data to be re-encrypted regularly by using newly-generated data encryption keys, so that data security is maintained or increased. The enforcement or practice of such security polices results in a required down time for applications for each time data is re-encrypted using newly-generated data encryption keys. The regular shutdown of applications while the volume data is being regularly re-encrypted results in a longer downtime period that may not be acceptable for some customers (e.g., customers who use enterprise computing systems). Therefore, the current technology is subjected to at least the above constraints and deficiencies.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

FIG. 1is a block diagram of a system (apparatus)100in accordance with an embodiment of the invention. The system100is typically a computer system that is in a computing device. A user space105will have one or more application software110that will run in the system100. A key database112(or application112) provides the public-private key pairs used to protect data encryption keys that in turn are used for encrypting the data in the volumes135, as discussed below. A kernel space115includes an operating system management module120with various known operating system elements such as, for example, a virtual memory subsystem121, networking subsystem122, process management subsystem123, disk I/O subsystem124, and file system140, and/or other known subsystems that permit an operating system to perform various known functions. The OS management module120can also include kernel data structures to permit various operating system operations and/or other modules that can be loaded into the kernel space115.

A hardware space125includes a processor130for performing processing functions and disk resources that includes one or more volumes135. A volume135is typically formed in a physical storage disk137. Other standard elements in the computer system100are not shown inFIG. 1for purposes of focusing the discussion on features of embodiments of the invention.

The kernel space115also includes a system call interface136for receiving and transmitting the system calls between the user space105and the kernel space115. A file system140manages the files and folders that are stored in the volumes135in the hardware space125. A volume manager145manages the storage of data in the volumes135. A storage device driver147reads data from (or writes data to) the volumes135, in response to a read request or write request, respectively, from the user space105.

In accordance with an embodiment of the invention, a conversion daemon150and data encryption driver155are used for performing an online data conversion method as will be discussed below in additional details. Data conversion can be three different scenarios or types: configuration, re-keying, or de-configuration. Configuration is the operation of converting plain text data (non-encrypted data) into cipher text data (encrypted data). Re-keying is the operation of changing the encryption keys of a currently-encrypted data. De-configuration is the operation of converting cipher text data into plain text data. As also discussed in the various examples below, each of the configuration scenario, re-keying scenario, and de-configuration scenario typically includes a preparation phase, conversion phase, and cleanup phase. In the preparation phase of the configuration scenario, a volume is first extended and encryption metadata (EMD) is written in the volume space that is formed by extending the volume. As an example, a volume is extended by an amount that is equal to approximately two times the size of the EMD. In order to extend a volume135, the volume manager145(FIG. 1) reserves (allocates) an appropriate amount of disk blocks in a physical disk137that contains the volume135. For example, the amount of disk blocks that are allocated for the extended space of the volume is equal to about two times the size of the EMD. Each disk block is, for example, 1 KB of disk space in the disk137. However, it is within the scope of embodiments of the invention for a disk block to be at other sizes. These allocated (reserved) disk blocks will form the extended volume space, and the conversion daemon150(FIG. 1) will then write the EMD in this extended volume space, as will be discussed further in the examples below. Disk block allocation techniques that are performed by volume managers are known to those skilled in the art. It is also noted that in the re-keying scenario and de-configuration scenario that will be discussed below, the volume extension step is not necessary since this extended space was previously allocated by the volume manager145during the previous configuration phases, and this extended space has not yet been released (i.e., de-allocated) from the volume.

Reference is first made toFIGS. 2A-2Ein order to illustrate an online data conversion method in accordance with an embodiment of the invention, where plain text is converted to cipher text (encryption method). Note that examples of cipher text to plain text data conversion (decryption method) and cipher text to cipher text data conversion (re-keying method) will also be discussed below. Prior to the preparation phase, the initial volume is shown as volume135inFIG. 2A. During the preparation phase, the volume manager145will extend the volume135. As mentioned above, a volume135can be extended by allocating additional disk blocks for the volume. As an example, a volume is extended by an amount that is equal to approximately two times the size of the encryption metadata (EMD). The size of the EMD is typically fixed. For example, if the EMD is 2 MB, then the volume135is extended by space201(FIG. 2B) of size 4 MB. The extended volume spaces201aand201bare each 2 MB in this example. At this time, spaces201aand201bare free spaces (unused disk blocks).

InFIG. 2C, the preparation phase has been completed and the EMD202has been written by the conversion daemon150(FIG. 1) into the extended space201b(which is at one end of the volume135). The EMD202is formed by a new key202a(which is an encryption key to be used for the encrypted data214in the volume135) and persisted info202b(which indicates the size, movement direction, and position of a window203that is to be discussed below). The area230in the extended space201bremains as a free space since area230does not contain any of the EMD202. Note also that additional known encryption techniques are used for the encryption key202asuch as, for example, encrypting the encryption key202awith a public key.

In an embodiment of the invention, a window203will slide from one end of the volume135to the other end of the volume135. The size of the window203is typically equal to the size of the EMD202in the configuration (plain-to-cipher text conversion) scenario and in the de-configuration (cipher-to-plain text conversion) scenario. In the re-keying (cipher-to-cipher text data conversion) scenario, the size of the window203is typically equal to a free space area (reserved area) in an extended volume space after the EMD is stored in the extended volume space, as discussed in an example below.

The data encryption driver155(FIG. 1) views the entire volume135as partitioned into two sections: (1) the old Section211which contains the old data (i.e., data prior to performing the conversion) and (2) the new Section212(FIG. 2D) which contains the converted data (i.e., the old data after performing the conversion). The sliding window203is positioned at the end of the old Section211and covers the plain text data206. Therefore, inFIG. 2C(which occurs after the preparation phase and before the conversion phase), the sliding window203is covering the plain text206which is part of the old section211.

The conversion daemon150watches the amount160(FIG. 1) of available processor cycles and an amount161of available disk I/O (input/output) bandwidth. The processor cycles are the resources in the processor130that are being consumed by software threads or processes in the system100. The disk I/O bandwidth is the bandwidth resources that are being consumed by requests to the disks137. The process management subsystem123(FIG. 1) can track the amount160of available processor cycles by measurement of the processor load. The disk I/O subsystem124can track the amount161of available disk I/O bandwidth by measurement of the disk I/O bandwidth load. Alternatively, the amounts160and161are values that indicate processor load or disk I/O bandwidth consumption, respectively.

If the amount160of available processor cycles160is above (or has reached) a threshold value T1and the amount161of available disk I/o bandwidth is above (or has reached) a threshold value T2, then the conversion daemon150will perform the read-convert-write-slide steps below in order to convert the data within a window203(e.g.,FIG. 2C) in the volume135. The threshold values T1and T2can be tunable or adjustable by a user. Relatively higher values of T1and T2will have lesser impact on the performance of applications and increase the amount of time to perform the data conversion, because less time slots are being used to perform the data conversion and more time slots will be available for use by the applications. Relatively lower values of T1and T2will increase the impact on the performance of applications and decrease the amount of time to perform the data conversion, because more time slots are being used to perform the data conversion and less time slots will be available for use by the applications.

During the conversion of data, the conversion daemon150will read the plain text206in the window203, then convert the plain text206into the cipher text214(FIG. 2D), then write the cipher text214in the space201ain volume135, and then slide the window203in the direction208in order to convert the additional plain text209into cipher text214. The conversion daemon150will then again wait for the available processor cycles and available disk I/O bandwidth to increase above the threshold values T1and T2, respectively. When the available processor cycles160has reached (or goes above) the threshold value T1and the available disk I/O bandwidth has reached (or goes above) the threshold value T2as discussed above, then the conversion daemon150can again perform the above read-convert-write-slide steps in order to convert the plain text209in window203into cipher text214. The converted data from plain text209is written by the daemon150as cipher text into the adjacent free space219. As a result, the converted data214does not overwrite any current data in the volume135because the converted data214is always being written into free space. This feature eliminates the occurrence of data corruption during unexpected system re-boot because no current data is overwritten by the converted data214.

The conversion daemon150will perform the above watch step and read-convert-write-slide steps until the window203has reached the beginning boundary210of volume135.

As shown inFIG. 2D, during the conversion phase, the window203slides in the direction208. The conversion daemon150(FIG. 1) converts the plain text209that is overlapped by the window203. The window203slides in direction208until reaching the beginning boundary210of the volume135. The beginning boundary210(which is formed by the first disk block of the volume135) is typically identified by encryption metadata (EMD) that is maintained by the encryption driver155(FIG. 1). The new section212will contain the encrypted data (cipher text data)214. The section215(FIG. 2E) will initially be a free space that will then subsequently store the EMD202. The volume135will contain the cipher text data214and will not contain the plain text data when the conversion phase has been completed inFIG. 2E. Also, the beginning section215will contain the free space216because the EMD202will not occupy all of the disk blocks in the beginning section215.

FIG. 2Eshows the volume135after the cleanup phase. In the cleanup phase, the conversion daemon150copies the EMD202from the extended section201bto the beginning section215of the volume135. The daemon150also deletes the EMD202from the extended section201bat the bottom end of the volume135. As a result, the extended section201bat the bottom end of the volume135will contain free space. The benefit of having the free space at extended section201bwill be discussed below.

Note that the window203will overlap a given number of disk blocks. In an implementation, the window203is typically 1 MB in size. However, in a simplified example, if a window203is 10 KB in size, then the window203will overlap 10 disk blocks (data blocks) where each disk block is, e.g., 1 KB. As known to those skilled in the art, a volume manager145identifies a disk block by its disk block number. InFIG. 2C, the window203is currently overlapping, for example, the disk block numbers #50to #59. Therefore, the conversion daemon150will read (typically by use of storage driver147inFIG. 1) the plain text206in disk block numbers #50to #59, store this plain text206in a buffer180(FIG. 1), and the conversion daemon150will then convert this plain text data206into the cipher text214. The conversion daemon150will then write this cipher text data214into the section201awhich would contain, for example, the disk block numbers #60to #69and which is the free space that is adjacent to the current position of window203.FIG. 2Dshows the cipher text data214as having been written into the section201aof volume135.

InFIG. 2D, the window203is overlapping, for example, the disk block numbers #40-49. The conversion daemon150performs the similar method above so that the plain text209is converted into cipher text214which would then be written into the section219which contains disk block numbers #50to #59and which is adjacent to the current position of window203.

FIGS. 3is a state diagram of the various states of the data encryption driver155(FIG. 1) during the conversion phase, in accordance with an embodiment of the invention. It is noted that the state diagram ofFIG. 3applies to the plain text to cipher text conversion steps in the example ofFIGS. 2A-2Eand to the below discussed examples of cipher text to plain text conversion and cipher text to cipher text conversion.

In the online state301, the conversion daemon150(FIG. 1) is not watching for the available processor cycles and available disk I/O bandwidth to surpass (or reach) T1and T2, respectively, and is also not performing any conversion of the data in the window203. The data encryption driver155services requests170(FIG. 1) (e.g., reads or writes) from an application110to the volume135. If the read or write request170is for data that is in new section212(FIG. 2D), then the driver155will decrypt the data read from the volume135into plain text for transmission to the application110and encrypt the data into cipher text before transmitting to the volume135for writing. If the read or write request170is for data that is in old section211(FIG. 2D), then the driver155will proceed with the read or write requests to the volume135without any data transformation.

When the conversion daemon150(FIG. 1) is watching for available processor cycles and available disk I/O bandwidth to surpass (or reach) the threshold values T1and T2, respectively, the driver155(FIG. 1) is in state S1. When the threshold values T1and T2are surpassed (or reached), the daemon150will signal172(FIG. 1) the driver155to move to state S2.

In state S1, the driver155processes all incoming reads or writes to the old section211(FIG. 2C). If a read or write request extends to both the old section211and new section212, then the driver155will break the request into two separate requests (one request for each section) and then proceed to process each read or write requests to the volume135. Therefore, in state S1, the driver155continues to perform normal processing of requests such as, for example, it encrypts the data before it sends to the volume135and decrypts of data after it reads from the volume135for the requests in new section212. The driver155does not transform data for the reads and writes in old section211.

In state S2, the conversion daemon150is using processor cycles and disk I/O bandwidth to perform the above mentioned read-convert-write-slide steps for converting the volume data in a window203(FIG. 2C). In state S2, since the conversion daemon150is converting the data (e.g., data206inFIG. 2C) that is overlapped by the window203, the driver155will hold all requests170(FIG. 1) in a queue171(FIG. 1), if the requests170is for the data that is overlapped by the window203. The driver155also processes all other incoming requests170for other volume data that are not currently overlapped by the window203.

The conversion daemon150(FIG. 1) uses signal172to the driver155to change its state. When the conversion daemon150requests the driver155to change between the above states (online, S1and S2), the driver155will first buffer the incoming request(s)170and the daemon150will wait for the completion of any in-progress reads/writes. The daemon150then performs the read-convert-write-slide steps. The driver155can then release the incoming request(s)170that were previously buffered so that the read or write operations to the volume135can continue.

Note also that when the state of the driver155moves from online301to S1(FIG. 3), the daemon150will mark the start position of the window203into the persistent info area202b(FIG. 2C), so that the position of the window is recorded into a metadata. As discussed above, during state S1, the daemon150is performing the above mentioned watch step. When the state of the driver155moves from S1to S2, the daemon150will be performing the above-mentioned read-convert-write-slide steps.

When the state of the driver155moves state S2to state S1, the daemon150has completed the window slide step (i.e., the-sliding of the window208in direction208as best shown in the example ofFIG. 2D) and will be performing the watch step. The daemon150will also mark the new position of the window203in the persistent info area202b(FIG. 2C) since the window203has moved to the new position. As a result, since the new position of the window203is recorded in metadata, the daemon150can determine this new position of the window203in the event of a system crash and system re-start. Any buffered requests170in the queue171are also released by the driver155so that reads or writes are performed on the volume135.

When the state of the driver155moves from state S2to online state301, the daemon150has converted all of the appropriate data in the volume135. The daemon150marks the end position210(FIG. 2D) into the persistent info area202bto indicate that all of the appropriate data in the volume135has been converted. Additionally, any buffered requests170in the queue171are also released by the driver155so that reads or writes are performed on the volume135.

FIG. 4is a flowchart of a method400that is performed by the daemon150, in accordance with an embodiment of the invention. In block405, the daemon150is not yet performing any operations related to data conversion. The driver155is also currently in the online state301.

In block410, the daemon150performs the watch step which involves watching for available processor cycles and available disk I/O bandwidth to surpass (or reach) the threshold values T1and T2, respectively. The driver155will also move from the online state301to state S1. If the threshold values T1and T2are not surpassed (or not reached), then daemon150remains in block410as shown by the loop411.

If the threshold values T1and T2are surpassed (or reached), then the daemon150will perform the read step in block415. The daemon150will request the driver155to change its state to S2and will read the data that is overlapped by the window203for storage into a buffer180(FIG. 1). Since the buffer180will store the data that is read from window203, an embodiment of the invention advantageously avoids the backup step of previous approaches. This backup step involves backing up the entire volume data into a backup media and this backup step results in additional downtime for the applications that need to read or write data to the volume135. In block415, the driver155will move from state S1to state S2.

In block420, the daemon150will convert the data that has been read from the window203in the volume135and buffered in the buffer180. The conversion can be from plain text to cipher text conversion (i.e., data encryption) as discussed inFIGS. 2A-2Eabove. The conversion can be from cipher text to plain text conversion (i.e., data decryption) as discussed below. The conversion can also be from cipher text to cipher text conversion (i.e., re-keying) as discussed below. The cipher text to cipher text conversion involves converting the cipher text data (that is encrypted by an encryption key) into plain text and then converting the plain text data into cipher text data (that is encrypted by a different encryption key). In block420, the driver155remains in state S2.

In block425, the daemon150will write the converted data into the volume135. As discussed above, the daemon150writes the converted data only in free spaces in the volume135, and this feature advantageously avoids the corruption of data in the volume135. Typically, this free space for receiving the converted data is in a volume area that is next to the current position of the window203as shown in, for example,FIGS. 2C and 2D. In block425, the driver155remains in state S2.

In block425, the daemon150will slide the window203to the next set of disk blocks in the volume135. The window203will slide in a space amount that is equal to the window size so that a next set of data are converted by the daemon150. In block430, the driver155remains in state S2.

In block435, if this next set of disk blocks (on which the moved window203now overlaps) is at the end boundary of the volume, then in block440the daemon150ends the watch-read-convert-write-slide cycle445and the driver155moves from state S2to the online state301. On the other hand, in block435, if this next set of disk blocks (on which the moved window203now overlaps) is not at the end boundary of the volume, then the daemon150moves (via loop446) to block410to again perform the watch step and the driver155moves from state S2to state S1. The daemon150will watch for available processor cycles and available disk I/O bandwidth to surpass the threshold values T1and T2, respectively, in order to convert the data that is currently overlapped by the window203.

The conversion daemon150(FIG. 1) commits (stores) the size, movement direction, and position of the window203in a persistent info area202bof the EMD202at the end of each watch-read-convert-write-slide cycle445. If a system crash interrupts the conversion process (i.e., any of steps415-430), the conversion daemon150retrieves the position of the window203in the volume135from the persistent info area205and resumes processing automatically after system re-start by continuing the watch-read-convert-write-slide cycle445.

FIGS. 5A-5Eillustrates an online data conversion method in accordance with an embodiment of the invention, where cipher text is converted to plain text (decryption method). Note that the volume extension step is not necessary in this example, because the disk blocks of the extended spaces201(FIG. 2B) were previously allocated to the volume135and have not yet been de-allocated from the volume135. The old section501of volume135will contain the cipher text214. The beginning section215of volume135contains the EMD202as well as free space216.

During the preparation phase, the daemon150will copy the EMD202and free space215in beginning section215to the end section201bwhich has free space.FIG. 5Bshows the volume135after the preparation phase. The daemon150will also delete the EMD202from the beginning section215. As a result, the beginning section215will have free spaces as shown inFIG. 5B.

InFIG. 5B, the preparation phase has been completed and the EMD202has been written by the conversion daemon150(FIG. 1) into the end section201b. The free space216is area in the end section201bthat is not occupied by the EMD202.

In an embodiment of the invention, a window203will slide from one end of the volume135to the other end of the volume in the direction502, as shown inFIG. 5C. The size of the window203is typically equal to the size of the EMD202in the de-configuration (cipher-to-plain text conversion) scenario. The sliding window203is positioned at the beginning of the old Section501and covers cipher text data only. Therefore, inFIG. 5B(which occurs after the preparation phase and before the conversion phase), the sliding window203is covering the cipher text505which is part of the old section501.

The conversion daemon150watches the amount160. (FIG. 1) of available processor cycles and an amount161of available disk I/O (input/output) bandwidth. If the amount160of available processor cycles160is above (or has reached) a threshold value T1and the amount161of available disk I/O bandwidth is above (or has reached) a threshold value T2, then the conversion daemon150will perform the read-convert-write-slide steps (steps415to430inFIG. 4) in order to convert the data in the volume135. During the conversion of data, the conversion daemon150will read the cipher text505in the window203, store the cipher text505in buffer180, and then convert the cipher text data505into a plain text. The daemon150will then write the plain text into the beginning space215(FIG. 5B) which currently contains free space.FIG. 5Cshows the new section507that contains the plain text data506which is data that has been converted from cipher data that has been read from the previous positions of window203.

InFIG. 5D, the cleanup phase has been performed. During the cleanup phase, the daemon150will delete the EMD202from the end space201bbecause the plain text506in the volume will no longer require the metadata for the encryption keys. Therefore, end space201bwill contain free space. The space201awill also contain free space because, as discussed above, the volume space adjacent to the sliding window203is maintained as a free space. Therefore, when the window203has reached the end boundary510(FIG. 5D) of the volume135, the space201a(which will be adjacent to the window203) will also be a free space.

InFIG. 5E, the volume135is contracted because the extended space201is de-allocated from the volume135. This de-allocation step typically involves the volume manager145(FIG. 1) performing a de-allocation (freeing up) of disk blocks that were reserved for the volume135.

FIGS. 6A-6Dillustrates an online data conversion method in accordance with an embodiment of the invention, where cipher text is converted to cipher text (re-keying method). The state of the volume135inFIG. 6Ais the same as the state of the volume135inFIG. 5A. The old section601of volume135will contain the cipher text214. The beginning section215of volume135contains the EMD202as well as free space216. The EMD202includes the key202awhich is an encryption key for the cipher data214. Note also that additional known encryption techniques are used for the encryption key202asuch as, for example, encrypting the encryption key202awith a public key.

During the preparation phase, the daemon150will create a new EMD602(FIG. 6B) which will contain a new data encryption key602afor re-encrypting the cipher text data into a new cipher text data as discussed below. Note that the data encryption keys are typically generated and encrypted using the public key obtained from the key database112(FIG. 1) by the conversion daemon150. The daemon150will write the new EMD602in the end section201bof volume135. Free space620will typically remain for disk blocks (in end section201b) that do not contain any of the EMD602information.

During the conversion phase, a window603(FIGS. 6B and 6C) will slide from one end of the volume135to the other end of the volume in the direction604, as shown inFIG. 6C. The size of the window603is typically equal to the size of the reserve space (free space)605(FIG. 6B), so that data to be converted in the window603can fit into free space605. The sliding window603is positioned at the start of the old Section601and covers cipher text data only.

The conversion daemon150watches the amount160(FIG. 1) of available processor cycles and an amount161of available disk I/O (input/output) bandwidth. If the amount160of available processor cycles160is above (or has reached) a threshold value T1and the amount161of available disk I/O bandwidth is above (or has reached) a threshold value T2, then the conversion daemon150will perform the read-convert-write-slide steps (as similarly discussed above) in order to convert the data in the volume135. During the conversion of data, the conversion daemon150will read the cipher text data607in the window603, store the cipher text data607into buffer180, and then convert the cipher text data607into a plain text data (in the buffer180). The daemon150will then convert this plain text data into new cipher data that uses the new data encryption key602a(FIG. 6B). Note that the persistent info data602bis similar to the previously discussed persistent info data202b(FIG. 2C) which tracks the size, position, and sliding direction of a window. The daemon150will then write the new cipher text609(which is uses the new key602a) into new section610of volume135. Note that the cipher data609that was converted from the cipher data607(in window603) is initially written in the free space605ofFIG. 6B. Free space611is always adjacent to the sliding window603and will store the converted text of the data currently overlapped by the window603.FIG. 6Cshows the new section610that contains the new cipher text data609which uses the new key602a.

InFIG. 6D, the cleanup phase has been performed. During the cleanup phase, the daemon150will copy the EMD602(including key602aand persistent info data602b) over the beginning section615of volume135. As previously mentioned above, the beginning section615previously contained the old key202a(for previous cipher text214) and old persistent info data202b. The daemon150will also delete the EMD602from the end space201bbecause the EMD602was copied to the beginning section615of the volume135. Therefore, end space201bwill contain free space. Free space620remains in a position adjacent to the end space201b.

FIGS. 7A-7Dillustrates an online data conversion method in accordance with an embodiment of the invention, where cipher text is converted to cipher text (re-keying method) for a second occurrence. The state of the volume135inFIG. 7Ais, for example, the same as the state of the volume135inFIG. 6D. The old section701of volume135will contain the cipher text609which uses the previously discussed data encryption key602a. Note that at this time, the EMD602(including the old key602a) will be in the beginning section615of volume135.

As previously mentioned above, re-keying is periodically performed by some businesses for purposes of improved data security. If the cipher text609will be converted to a new cipher text709(FIG. 7C) that uses the new data encryption key702a, then the below procedure will occur.

During the preparation phase, the daemon150will create another new EMD702(FIG. 7B) which will contain a new data encryption key702afor re-encrypting the cipher text data609into a new cipher text data709(FIG. 7C) as discussed below. The daemon150will write the EMD702in the end section201bof volume135. Free space721will typically remain for disk blocks (in the end section201b) that do not contain any of the EMD702information.

During the conversion phase, a window703(FIGS. 7B and 7C) will slide from one end of the volume135to the other end of the volume in the direction704, as shown inFIG. 7C. The size of the window703is typically equal to the size of the reserve space (free space)620(FIG. 7B). The sliding window703is positioned at the end of the old Section701and covers the cipher text data609only.

The conversion daemon150watches the amount160(FIG. 1) of available processor cycles and an amount161of available disk I/O (input/output) bandwidth. If the amount160of available processor cycles160is above (or has reached) a threshold value T1and the amount161of available disk I/o bandwidth is above (or has reached) a threshold value T2, then the conversion daemon150will perform the read-convert-write-slide steps (as similarly discussed above) in order to convert the data in the volume135. During the conversion of data, the conversion daemon150will read the cipher text data707in the window603, and then convert the cipher text data707into a plain text data (in the buffer180). The daemon150will then convert this plain text data into the new cipher data709that uses the new data encryption key702a(FIG. 7B). Note that the persistent info data702bis similar to the previously discussed persistent info data202b(FIG. 2C) which tracks the size, position, and sliding direction of a window. The daemon150will then write the new cipher text data709(which is uses the new key702a) into new section710of volume135. Note that the cipher data709that was converted from the cipher data707(in window703) is initially written into the free space620ofFIG. 7B. The window703and free space620are at the same sizes so that any data read from window703can fit as a converted data into the free space620. Free space711is always adjacent to the sliding window703and will store the converted text of the data currently overlapped by the window703.FIG. 7Cshows the new section710that contains the new cipher text data709which uses the new key702a.

InFIG. 7D, the cleanup phase has been performed. During the cleanup phase, the daemon150will copy the EMD702(including key702aand persistent info data702b) over the beginning section602of volume135. As previously mentioned above, the beginning section602previously contained the old key602aand old persistent info data602b. The daemon150will also delete the EMD702from the end space201bbecause the EMD702was copied to the beginning section602of the volume135. Therefore, end space201bwill contain free space. Free space720remains in a position adjacent to the end space602.

An embodiment of the invention provides the above discussed online data conversion methods that have various advantages. First, the downtime for applications is reduced because an embodiment of the invention eliminates the required backup step of previous systems. In contrast, an embodiment of the invention permits an application downtime to only occur during the preparation phase and clean up phase, and application downtime is minimized to typically only a few minutes. Second, an embodiment of the invention performs the online data conversion when the available processor cycles and available disk I/O bandwidth are above threshold values which are tunable. Therefore, the user can set the performance impact on the applications to be at a minimum during the online data conversion process. Third, free space is always adjacent to the sliding window and will store the data converted from the original data that is overlapped by the window. Therefore, the converted data will not overwrite any current data in the volume. Additionally, metadata (persistent info data) that indicates the size, position, and direction of the window is maintained and accessed by the conversion daemon150. This free space and persistent info data advantageously avoids the occurrence of data corruption after system re-start, as discussed above.

It is also within the scope of the present invention to implement a program or code that can be stored in a machine-readable or computer-readable medium to permit a computer to perform any of the inventive techniques described above, or a program or code that can be stored in an article of manufacture that includes a computer readable medium on which computer-readable instructions for carrying out embodiments of the inventive techniques are stored. Other variations and modifications of the above-described embodiments and methods are possible in light of the teaching discussed herein.