Method and apparatus for moving data between storage devices

System administrators are able to move data between volumes to better utilize system resources. As data is being moved, clients are able to access and modify the data from the source volume. The apparatus moves the data by repeatedly traversing the file system on the source volume and copying files to the destination volume. Modifications made by clients to the source volume are logged. Once the data has been moved the destination volume is updated with all client modifications.

FIELD OF THE INVENTION

This invention relates to moving data between storage devices in a computer system, and more particularly to minimizing the time data is unavailable to consumers.

BACKGROUND OF THE INVENTION

Organizations and users have an ever-growing need to store data on computer networks. Often, system administrators expand existing systems with additional devices capable of meeting demands. To take advantage of network growth, and to generally improve the distribution of data storage, system administrators need the ability to move data between storage devices.

Currently, when moving data, system administrators have to deny users access to any of the data being moved. Denying access to data for any period of time is generally undesirable. And for large networks that contain vast amounts of mission-critical data that is vital to the operation of an organization, denying users access to data may result in adverse consequences.

Some techniques exist to alleviate this problem. For example, system administrators generally schedule operations that deny access to users during time periods when networks experience the least amount of traffic. As demands on networks increase, this technique becomes more problematic. For example, users may require uninterrupted access to data for a host of reasons specific to their operations. And as the amount of data on networks grows, the time required to process the data increases.

A need exists to provide users' access to files in the process of being moved, preferably in a manner that is both convenient and efficient. A solution that meets this demand would preferably address these problems and other problems associated with the prior art.

SUMMARY OF THE INVENTION

The invention is a method and apparatus for moving data from a source volume to a destination volume that minimizes the time files are unavailable to consumers. A system administrator issues a command to move files from a source volume to a destination volume. As the system moves files from the source volume to the destination volume, the system identifies files that could not be moved. The system also identifies files that have been modified (including created or deleted) after they were moved, so that the modifications can be replicated on the destination volume.

The foregoing and other features, objects, and advantages of the invention will become more readily apparent from the following detailed description, which proceeds with ten references to the accompanying drawings.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1shows a computer operative to move files from a source volume to a destination volume, according to an embodiment of the invention. InFIG. 1, computer105acts as a server, allowing others to access data. But a person skilled in the art will recognize that computer105does not have to be limited to a server, and can be any variety of devices capable of allowing others to access data.

Computer105includes file system110, which manages the storage of data on source volume115. FIG. Similarly, file system190manages the storage of data on destination volume120. Volumes are stored on storage media such as source media125and destination media130, and can also span multiple physical storage devices, if needed (for example, a storage area network (SAN)). Both source media125and destination media130can be physically within the box that is computer105, or they can be remote from computer105, as required. Also, both source volume115and destination volume120can be physically within the box that is computer105, or they can be remote from computer105, as required, and even in different computers. Typically, source volume115and source media125are contained on computer105, but a person skilled in the art will recognize that source media125and source volume115can be on a computer other than computer105.

In the server embodiment, a client, such as client135, interacts with computer105. Client135is shown as a desktop computer system, including computer140, monitor145, keyboard150, and mouse155, but a person skilled in the art will recognize that client135can take other forms. For example, client can be, among others, a dumb terminal, an Internet appliance, or a handheld computing device, with the accordant variations in configuration.FIG. 1does not show additional components that can be part of client135, such as a printer or other input/output devices, nor doesFIG. 1show the typical components that comprise client, such as the central processing unit, memory, local storage, etc.

A system administrator can use system administrator computer160to interact with computer105. As with client135, system administrator computer160can be any form of computer, and is not limited to using any particular embodiment of a computer. Typically, client135and system administrator computer160interact with computer105across a network, such as network165. Network165can be any variety of network including, among others, a local area network (LAN), a wide area network (WAN), a global network (such as the Internet), and a wireless network (for example, using Bluetooth or any of the IEEE 802.11 standards). A person skilled in the art will recognize that client135and system administrator computer160can have a direct connection to computer105, without crossing a network. System administrator computer160can also interact with computer105directly without using any type of intermediate computer or network.

Also connected to network165is volume location database (VLDB)185. VLDB185associates volume names with a globally unique identifier (GUID) and the physical location of volumes. User requests for access to particular volumes are handled by referring to VLDB185in order to resolve the physical location of the volume requested.

System administrator computer160uses interface170to interface with volume manager175in computer105. Interface170is responsible for translating messages between system administrator computer160and volume manager175. Interface170processes two messages of interest from system administrator computer160: volume move and volume split. Each of these actions is described below in turn.

When system administrator computer160issues a volume move command and specifies source and destination volumes, interface170transmits the command to volume manager175. Volume manager175moves all data contained on the source volume, such as source volume115, to the destination volume, such as destination volume120. Typically, destination volume120is contained on a remote computer like computer180, which acts as a server allowing others to access data. But a person skilled in the art will recognize that computer180does not have to be limited to a server and can be any variety of devices allowing others to access data. The volume manager175updates the VLDB185with the location of the destination volume. Updating VLDB185has the effect of directing user requests for files, previously obtained from the source volume, to the destination volume.

When system administrator computer160issues a volume split command and specifies source and destination volumes, system administrator computer160can also specify a folder of files contained on source volume115that will be moved to destination volume120. Interface170transmits the commands of system administrator computer160to volume manager175. Volume manager175moves the folder of files contained on source volume115to destination volume120, and inserts a junction into source volume115. A junction acts as a “link” between volumes, making the destination volume120appear as a subdirectory on source volume115. The junction stores the GUID of destination volume120so that requests for files that were split to destination volume120can be satisfied, giving clients the appearance that nothing has changed on source volume115.

During the split or move operation, client computers like client135can access files on source volume115. Clients are able to perform all of the normal file system activities, including but not limited to creating, deleting, renaming, and modifying files. Building an apparatus that allows a system administrator to move data while, at the same time, permitting users to access the same data has inherent challenges. Some files might be open for writing by users and, as a result, possibly incapable of being accessed. Also, because users are able to modify file system data after a file is moved, those changes need to be logged to insure that they are accurately reflected on the destination volume. The volume manager obtains a list of logged files so that the destination volume can be updated with the modified files.

FIG. 2shows volume manager175configured to obtain a list of files that are modified during an interval of interest, according to an embodiment of the invention. U.S. patent application Ser. No. 10/283,960, filed Oct. 29, 2002, now pending and incorporated by reference herein, describes a system and method for managing events. As client135interacts with files managed by file system110of computer105, the interactions generate events. For example, when client135saves a file to the file system110, the act of saving the file is an event. Other common types of client-triggered events of interest include modifications to either the data or metadata of files, deletions of files, and renamings of files. Other events can occur without the involvement of a particular client. For example, a scheduled archive of files in file system110can change the metadata of the files, triggering events. File system110forwards these events to event list manager205, which stores the events in event storage210. Event list manager205is responsible for storing events as they are generated by file system110and responding to computer processes interested in receiving event lists. Volume manager175defines an interval of interest with event list manager205and receives a list of files that were modified during that interval of interest. Volume manager175uses the list received from event list manager205to transmit changes that occur on file system110to file system190. InFIG. 2file system190is shown in computer180, but a person skilled in the art will recognize that file system190(and destination media130, which is not shown inFIG. 2), can be part of computer105.

In one embodiment, volume manager175uses file system read and write commands (typically in extensible Markup Language (XML)) to communicate with event list manager205. In a second embodiment, volume manager sends a Simple Object Access Protocol (SOAP) XML stream to communicate with the event list manager. In either case, volume manager175sends a message to event list manager205that declares the start of an epoch and requests that events involving file modifications, including file deletion, renaming, and creation be associated with the epoch. Before the list of modified files may be obtained, the active epoch is closed. Volume manager175closes the active epoch with event list manager205by sending a message declaring the end of the epoch or a message beginning a new epoch. Once the epoch is closed, volume manager175sends a message to event list manager205requesting the list of modified files. In response, event list manager205sends a list of files that were associated with the epoch to volume manager175. Further description of the method for obtaining a list of modified files from event list manager205is described below.

AlthoughFIG. 2shows event list manager205as part of computer105, a person skilled in the art will recognize that event list manager205can be remote from computer105. In other words, event list manager205can be operating on a computer distinct from computer105, and which interacts with computer105either via a direct connection or across network165.

FIG. 3shows folder structure305contained on source volume115prior to the start of a split operation. Items on the source volume115subject to the split operation are contained in folder315. All files, such as file2.txt320, contained in folder315are to be moved from source volume115ofFIG. 3to destination volume120ofFIG. 4. The contents of folder structure410on destination volume120after the split operation is complete are shown inFIG. 4. In this embodiment, the structure and hierarchy of folder315(FIG. 3) are the same on destination volume120(FIG. 4) as source volume115(FIG. 3).

The volume manager traverses the listings of folder315(FIG. 3) attempting to copy each file from source volume115(FIG. 3) to destination volume120(FIG. 4). During the traverse of the set of files subject to the split operation, the volume manager keeps two lists, discussed further below with reference toFIG. 5. A person skilled in the art will recognize that the two lists can use any of a number of different data structures capable of holding data. The first list identifies files that were not capable of being copied to the destination media (this can happen, for example, if the file is open for writing by a client). As the volume manager traverses folder315(FIG. 3), any file that cannot be copied is added to the first list of files. The second list contains files that are modified after the system's initial attempt to copy them. In one embodiment, further described below, the volume manager obtains the second list of files from the event list manager.

FIG. 5shows one possible embodiment of first list505and second list510of files after the volume manager has completed a traverse of folder315(FIG. 3) subject to the split operation. InFIG. 5, file2.txt320appears on the first list505of files because volume manager was not able to copy file2.txt320to the destination volume120. Additional traverses or other procedures, as described below, are needed to copy file2.txt320and complete the split operation.

InFIG. 5, file3.txt520and file7.txt525appear on the second list510of files. The volume manager was able to copy both files to destination volume120during the traverse. However, both file3.txt520and file7.txt525were modified after the volume manager copied them. Modifications made to file3.txt520and file7.txt525are not accurately reflected on the destination volume120and additional traverses or other procedures, as described below, are needed to complete the split operation.

File6.txt325(FIG. 3) does not appear on either first list505or second list510ofFIG. 5. It does not appear on first list505because the volume manager was able to copy it to destination volume120, during the traverse. File6.txt325does not appear on the second list because modifications did not occur after it was copied to the destination volume. File6.txt325was moved without the need for any further procedures.

FIG. 6displays the folder605of destination volume120given the contents of the first and second list of files inFIG. 5. InFIG. 6, file2.txt does not appear on folder structure410of the destination volume120because the file has not yet been copied. InFIG. 6, file3.txt520and file7.txt525appear on the destination volume because both files were copied from the source volume. But since both file3.txt520and file7.txt525were modified after being copied, the versions of these files stored on destination volume120ofFIG. 6are not current.

FIG. 7shows source volume115and file system305after the split operation is complete. Volume manager places junction710into source volume115at the root of the folder that was split. As discussed earlier with reference toFIG. 1, a junction links one volume to a second volume. Junction710resolves user requests for files that were “split” by storing the GUID of the destination volume120, thereby allowing the computer105to obtain the physical location of files requested. The use of junction710presents clients with the appearance that nothing has changed in source volume115, even though a portion of the files in source volume115have been moved to destination volume120.

FIG. 8shows folder structure805contained on source volume115prior to a move operation. All files, such as file5.txt815, will be moved from source volume115ofFIG. 8to destination volume120ofFIG. 9. The contents of the destination volume after the move operation is complete are shown in folder structure905ofFIG. 9. In this embodiment, the structure and hierarchy of folder structure805(FIG. 8) are the same on destination volume120(FIG. 9) as source volume115(FIG. 8).

In both the volume move and volume split operations, the technique for copying files is the same. As described above with reference to a volume split (FIG. 3andFIG. 4), the volume manager keeps two lists of files (seeFIG. 5) when traversing a directory subject to a volume move operation. The first list identifies files that were not capable of being copied to destination volume120(FIG. 9). The second list contains files that were modified after the volume manager's initial attempt to copy them from source volume115(FIG. 8) to destination volume120(FIG. 9). If a file appears on either list, than additional traverses or other procedures are required to complete the move or split operation.

Even though the technique for copying files is the same in a volume split and volume move there are differences between the two operations. In a volume move the entire contents of a volume are moved, whereas in a volume split only involves moving a folder of a volume. Also, in a volume split, after the “move” portion of the operation is complete, the volume manager places a junction into the source volume at the root of the subdirectory tree that was moved.

FIGS. 10A-10Bshow a flowchart of the procedure for copying files from the source volume to the destination volume of computer inFIG. 1, according to an embodiment of the invention. InFIG. 10Aat step1005, a system administrator issues either a volume move or volume split command, which is transmitted to volume manager from the interface of computer inFIG. 1.

At step1010(FIG. 10A), the volume manager determines whether the command is a volume split or a volume move. If the command is a volume split, the volume manager creates a destination volume that will be responsible for managing the files subject to the split operation. Creating the destination volume includes assigning a GUID and associating the GUID with the physical location of the destination volume in the VLDB.

Note that in the case of a volume move, step1010is not performed. Instead, the VLDB is updated at step1060(FIG. 10B). The reason that the VLDB is not updated at step1010in the case of a volume move is that for a volume move, the volume name is not changed. Thus, if the destination volume were added to the VLDB before the source volume was removed, the VLDB would list two different possible volumes for a volume request. Requests to access the volume by name might be directed to the destination volume, which might not yet have the desired file (or might have an out-of-date version of the file). Instead, the files are copied to the destination volume before the VLDB is updated, and the VLDB is updated only when the volume move operation is complete.

At step1015(FIG. 10A), the volume manager defines an interval of interest with the event list manager. As described previously, the event list manager is responsible for storing events as they are generated by a file system and responding to computer processes interested in receiving event lists. The volume manager defines an interval of interest with the event list manager in which files that are modified, created, renamed, or deleted are added to the second list of files created in step1020(FIG. 10A). In one embodiment, the volume manager declares an epoch with the event list manager. Then, after a first pass has been made over the files to be moved, the volume manager can request from the event list manager events specifying files that have been modified since the epoch was declared.

InFIG. 10Aat step1020, volume manager creates two empty lists capable of storing data as described above.

In step1025the volume manager traverses the directory of files subject to a system administrator's move or split command attempting to copy each file from the source volume to the destination volume. The file duplications can be accomplished using file system Application Program Interfaces (APIs), although a person skilled in the art will recognize that other techniques can be used to copy the files. The volume manager determines whether each file is capable of being copied and copies files whose transmission is permitted. Each file that is not capable of being copied is added to the first list of files.

At some point, the second list is populated with files that have been modified during the interval of interest (see step1015). A person skilled in the art will recognize that there are a variety of ways to populate the second list. In one embodiment, the volume manager requests events from the event list manager, and populates the second list with all files that were modified during the interval of interest. In this embodiment, some files on the second list could have been modified before the volume manager copied them. These files will be copied again even though all modifications are accurately reflected on the destination media. However, additional resources expended on these files is not significant because they are few in number. In a second embodiment, the event list manager updates the second list automatically with the files that were modified after the volume manager attempted to copy them. The event list manager obtains the time for the attempted duplication of each file from the volume manager. The time for the attempted duplication is compared to the time of the last event for each file. Through this comparison, the event list manager is able to populate the second list with files that were only modified after the volume manager's attempt to copy them. In a third embodiment, the volume manager populates the second list with files that were modified after the attempt to copy them. The volume manager obtains the time of the last event for each file from the event list manager. The time obtained from the event list manager is compared to the time the volume manager attempted to duplicate the file. Through this comparison, the volume manager is able to populate the second list with files that were modified after the volume manager's attempt to copy them.

InFIG. 10Aat step1030, volume manager examines the most recent instances of the first and second lists for entries. If both lists are empty, the process of copying files from the source volume to the destination volume (FIG. 1) is complete, as all files subject to the move or split operation have been copied. The process can then continue with step1050ofFIG. 10B.

Returning toFIG. 10A, if there is at least one file in one of the lists, then at step1035, the volume manager determines whether another traverse over the files subject to the move or split operation is needed. In one embodiment, the volume manager determines whether files were moved during the last traverse at step1025. The volume manager uses a counter to determine the number of files that were copied during the last traverse. If the volume manager finds that additional files were not copied on the last traverse then it proceeds back to step1020. However, a person skilled in the art will recognize that there are a number of ways to determine whether files were moved during a traverse of the file system. For example, the two lists can be examined to see if any files remain in the lists. The process for copying the remaining files is the same as described above for files that were previously copied, although the set of files to be copied is shorter.

InFIG. 10Aat step1035, if the volume manager determines that attempting to copy the files without locking out clients will not be useful, then further procedures are required to copy the remaining files. For example, if a file is left open for writing on a client computer for an extended period of time, repeatedly trying to copy the file will not help. In one embodiment, at step1040client access to files that are on the first and second lists is restricted. As a result, all remaining files are capable of being copied. InFIG. 10Aat step1045, the volume manager traverses the file system and copies all files that appear on the most recent instances of the first and second lists. After completion of step1045(FIG. 10A), all files subject to the move or split operation have been copied, and at step1047(FIG. 10A) the files are unlocked. The process can then continue with step1050ofFIG. 10B.

Once all files subject to the move or split operation have been copied, client requests for files are directed to the destination volume. InFIG. 10Bat step1050, the volume manager determines if the system administrator issued a volume move or volume split command.

If the operation is a volume split, then at step1055, the volume manager places a junction that contains the GUID of the destination volume into the source volume at the root of the subdirectory tree that was moved. As mentioned above, the use of a junction presents clients with the appearance that nothing has changed in the volume, even though a portion of the files in the source volume have been moved to the destination volume. Clients are able to access files on the subdirectory tree moved because a junction uses the GUID to direct client requests for the moved files to the destination volume.

If the operation is a volume move, the volume manager proceeds to step1060and updates the VLDB to reflect the move command. In a volume move, the entire contents of a volume are copied from the source volume to the destination volume. As described above with reference toFIG. 1, the VLDB associates volumes with their physical location on a storage device. Client requests for files are resolved by obtaining the physical location of the volume, that contains the files requested from the VLDB. To direct requests for files to the destination volume, the volume manager updates the VLDB changing the location of the source volume to that of the destination volume.

Once client requests for files are directed to the destination volume, the files subject to the move or split operation are deleted from the source volume. InFIG. 10Bat step1065, volume manager deletes file system data from the source volume. The resources used by the moved files are now free to store other data. In one embodiment, file system data is deleted as a background process. But a person skilled in the art will recognize that the deletion of file system data can be completed in any variety of ways.

A person skilled in the art will recognize that the flowchart shown inFIGS. 10A-10Bis one of many different sequences of steps that can be used to achieve the same results. For example, step1065(FIG. 10B) can be performed separately from the previous steps, possibly as part of regular system maintenance of deleting unnecessary files after a designated period of time.

A person skilled in the art will recognize that an embodiment of the invention described above may be implemented using a suitably programmed computer. In that case, the method is embodied as instructions that comprise a program (in this case, instructing a central processing unit how to execute other programs). The program may be stored on computer-readable media, such as floppy disks, optical disks (such as compact discs), fixed disks (such as hard drives), random access memory (RAM), read-only memory (ROM), or flash memory. The program may then be executed on a computer to implement the method. A person skilled in the art will also recognize that an embodiment of the invention described above may include a computer-readable modulated carrier signal, and that the program, or portions of its execution, may be distributed over multiple computers in a network.

Having illustrated and described the principles of the invention in an embodiment thereof, it should be readily apparent to those skilled in the art that the invention may be modified in arrangement and detail without departing from such principles. All modifications coming within the spirit and scope of the accompanying claims are claimed.