US20080104132A1 - Method and apparatus for splitting a replicated volume - Google Patents
Method and apparatus for splitting a replicated volume Download PDFInfo
- Publication number
- US20080104132A1 US20080104132A1 US11/555,105 US55510506A US2008104132A1 US 20080104132 A1 US20080104132 A1 US 20080104132A1 US 55510506 A US55510506 A US 55510506A US 2008104132 A1 US2008104132 A1 US 2008104132A1
- Authority
- US
- United States
- Prior art keywords
- volume
- replicated instance
- source volume
- dfs
- guid
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims description 32
- 230000010076 replication Effects 0.000 claims description 29
- 238000003860 storage Methods 0.000 claims description 23
- 238000012217 deletion Methods 0.000 claims description 4
- 230000037430 deletion Effects 0.000 claims description 4
- 230000001902 propagating effect Effects 0.000 claims 4
- 230000008569 process Effects 0.000 description 17
- 230000008901 benefit Effects 0.000 description 12
- 230000008520 organization Effects 0.000 description 8
- 238000013500 data storage Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 241000699666 Mus <mouse, genus> Species 0.000 description 1
- 241000699670 Mus sp. Species 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/11—File system administration, e.g. details of archiving or snapshots
- G06F16/119—Details of migration of file systems
Definitions
- This invention relates to moving data between storage devices in a computer system, and more particularly to moving data on a replicated storage device.
- a distributed file system is one where multiple file systems, each residing on a different storage volume, are connected to one another.
- the different storage volumes can be included in the same computer or in different computers connected together using a network.
- the file systems on the different storage volumes could have once been part of a single file system on a single storage volume. For example, when an organization is just starting out, the data storage requirements for that organization might be modest, and the organization is able to store all data on a single volume. After a while, as the organization grows, the original volume reaches its maximum storage capacity. Instead of simply starting a new volume from scratch, the organization may wish to divide the volume, moving a subdirectory tree from the volume to the new volume, while appearing to the client as though only a single volume is in use.
- volume replication allows a file system that is on one volume to be copied and made available to clients on one or more other volumes; each volume is typically called a replicated instance of the volume.
- Volume replication has several advantages. One advantage is that one replicated instance can act as a data backup in the event that another replicated instance of the same volume goes down. Another advantage of volume replication is that data can be moved closer to where the user needs it, thus potentially providing performance improvements in accessing and downloading the data.
- each replicated instance of the volume must be taken off-line before moving the desired subdirectory tree to the new volume. Taking each replicated instance off-line removes some the advantages that volume replication specifically provides. With each replicated instance off-line, the volume is not available.
- Another approach might be to take each volume off-line only as the volume split is being performed at each volume.
- This approach has the advantage that users can access data on one of the volumes: either the primary volume or the replicated instance of the primary volume. But if a replication method is used where there is a lag time between volume synchronization, then there is a possibility that the volume instances will have inconsistent data after the volume split occurs.
- At least two replicated instances of a source volume are split while allowing clients to access data moved during the split.
- Clients are redirected to the first replicated instance of the source volume.
- the first replicated instance is split by first moving files in a split path from the first replicated instance to the target volume. Then, after the files in the split path have been successfully moved to the target volume, a junction is inserted at the split directory to redirect clients to the target volume. After the first replicated instance is split, a second junction replaces the split path on the replicated instance of the first replicated instance.
- FIG. 1 shows a computer system configured to split a replicated volume while allowing clients to access the files that are moved from the volume, according to an embodiment of the invention.
- FIG. 2 shows a file system contained on the first replicated instance and the corresponding file system copy on the second replicated instance shown in FIG. 1 .
- FIG. 3 shows entries of the volumes shown in FIG. 1 in the volume location database (VLDB).
- VLDB volume location database
- FIG. 4 shows the first replicated instance of FIG. 1 before the files in the split path are moved to the target volume.
- FIG. 5 shows the temporary DFS GUID of FIG. 4 added to the VLDB.
- FIG. 6 shows a junction pointing to the split directory of the first replicated instance inserted at the split directory on the second replicated instance of FIG. 1 .
- FIG. 7 shows the target volume and first replicated instance of FIG. 1 after the contents of the split path are moved from the first replicated instance to the target volume.
- FIG. 8 shows the second replicated instance of FIG. 1 after the subdirectory tree is replaced with a junction to the target volume.
- FIGS. 9A-9B show a flowchart of the process of splitting the replicated volume shown in FIG. 1 .
- FIG. 1 shows a computer system configured to split a replicated volume while allowing clients to access the files that are moved from the volume, according to an embodiment of the invention.
- Computer 105 , computer 110 , and computer 115 connect to one another using network 120 .
- Computers 105 , 110 , and 115 can be servers or other machines to store and process data.
- Computers 105 , 110 , and 115 typically include a processor, memory such as random access memory (RAM), read-only memory (ROM), or other state preserving media, storages devices, and input/output interface ports not shown in FIG. 1 . Note that although FIG. 1 shows three computers, a person skilled in the art will recognize that any number of computers can be used.
- FIG. 1 shows two instances of a replicated volume. Any number of replicated instances can be used.
- Computer 105 includes first replicated instance 125 and target volume 130 .
- Computer 110 includes second replicated instance 135 .
- first replicated instance 125 and second replicated instance 135 are replicated instances of the same volume.
- First replicated instance 125 and second replicated instance 135 include file systems that are accessed by client computers across network 120 .
- the volumes are stored on storage media and can span multiple physical storage devices if needed (for example, a storage area network (SAN)).
- SAN storage area network
- Client computers can include desktop computer systems, including a computer, monitor, keyboard, and mouse.
- client computers can take other forms, such as, among others, dumb terminals, Internet appliances, or handheld computing devices such as personal digital assistants (PDAs).
- PDAs personal digital assistants
- first replicated instance 125 and second replicated instance 135 contain copies of the same files
- client computers can access either one of computer 105 or computer 110 . Considerations by the client computer as to which computer to connect to are addressed below with reference to FIG. 2 .
- Network 120 can 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).
- LAN local area network
- WAN wide area network
- Internet global network
- wireless network for example, using Bluetooth or any of the IEEE 802.11 standards.
- a volume is split when some files are moved from the volume to a new volume while other files are retained at the original volume.
- files in a directory or subdirectory on the original volume are moved to the new volume.
- a split directory refers to the directory or subdirectory identifying where the volume split occurs.
- the files and directories nested in the split directory make up a subdirectory tree referred to as a split path. Directories and files that are not in the split path remain on the original volume after the volume split.
- client computers can access files on the replicated volume, including files being moved to the new volume.
- 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.
- a list of logged files is maintained so that the new volume can be updated with the modified files.
- FIG. 1 shows target volume 130 included in computer 105 .
- Target volume 130 is the destination volume for data moved from the replicated volume as first replicated instance 125 is split.
- target volume 130 is shown as being part of computer 105 , a person skilled in the art will recognize that target volume 130 can be included in another computer connected to computer 105 over network 120 .
- target volume 130 can itself be replicated with any number of instances. If target volume 130 is replicated, the replication level and location of the replicated instances are specified when target volume 130 is created. This makes no difference to the split operation, as target volume 130 represents the instance where the files are moved.
- a replication manager responsible for maintaining consistency between replicated instances of a volume, such as first replicated instance 125 and second replicated instance 135 . Also, if target volume 130 is replicated, the replication manager is responsible for keeping the other instances of target volume 130 in sync.
- computer 105 includes volume manager 140 .
- Volume manager 140 performs the volume split of first replicated instance 125 .
- a system administrator can send a request to volume manager 140 identifying a split path on first replicated instance 125 to be moved to target volume 130 .
- the Moving Data application describes how volume manager 140 can split first replicated instance 125 while allowing clients to access the moved file during the volume split.
- computer 110 includes volume manager 175 that can split second replicated instance 135 .
- volume manager 140 and volume manager 175 interface with volume location database (VLDB) 145 stored on computer 115 .
- VLDB 145 associates volume names with a distributed file system (DFS) globally unique identifier (GUID) and the physical location of the volumes.
- DFS distributed file system
- GUID globally unique identifier
- VLDB 145 is accessible from most of the computers in the network.
- a client computer can access a particular volume instance by looking up the volume in VLDB 145 to resolve the physical location of the volume.
- VLDB 145 is described in greater detail below with reference to FIGS. 3 and 5 .
- clients seeking access to files in the split path of second replicated instance 135 are redirected to first replicated instance 125 as first replicated instance 125 is being split. If there are additional replicated instances of the volume, the split paths of these instances are also redirected to first replicated instance 125 .
- a junction identifying first replicated instance 125 is inserted in the split path of second replicated instance 135 . The use of a junction is discussed in greater detail below with reference to FIG. 6 .
- a symbolic link is used to redirect clients.
- Volume manager 140 includes DFS GUID creator 150 , junction creator 155 , and file verifier 160 to insert a junction to redirect client access to files on the split path of second replicated instance 135 .
- volume manager 175 also includes these elements.
- DFS GUID creator 150 creates a temporary DFS GUID to assign to first replicated instance 125 .
- DFS GUID creator 150 looks for a unique identifier to be assigned to first replicated instance 125 . Then, if a client identifies a junction with the temporary DFS GUID, the client can look up the temporary DFS GUID in VLDB # 145 and identify first replicated instance 125 as the appropriate volume for redirection. If temporary DFS GUID is not unique, then the client might redirect to another volume in error.
- junction creator 155 inserts a temporary junction at the split directory of second replicated instance 135 .
- a junction acts as a “link” between volumes, connecting two volumes using a DFS GUID in the junction to point from one volume to another volume.
- the client represents the junction as a subdirectory to the end user.
- the inserted junction includes the temporary DFS GUID that is assigned to first replicated instance 125 .
- the client looks up the temporary DFS GUID in VLDB 145 to identify the name and location of the volume assigned that DFS GUID.
- Inserting a junction with the temporary DFS GUID at the split directory of second replicated instance 135 in effect takes the split path of second replicated instance 135 off-line. Note that as the junction is in the split path of second replicated instance 135 , the benefits of volume replication are temporarily suspended for the files in the split path, with only first replicated instance 125 accessible for those files. Finally, when inserting the junction with the temporary DFS GUID at the split path of a replicated instance other than the instance where the volume split occurs, volume manager 140 notifies the replication manager to not replicate the temporary junction.
- file verifier 160 verifies that each file copy in the split path of second replicated instance 135 is closed.
- File verifier 160 is discussed in greater detail below with reference to FIG. 6 .
- first replicated instance 125 is temporarily the sole volume available for client access for files in the split path.
- Volume manager 140 then splits first replicated instance 125 .
- subdirectory mover 165 performs the split of first replicated instance 125 while clients can access and modify files on first replicated instance 125 .
- junction remover 170 removes the temporary junction from second replicated instance 135 .
- Volume manager 140 then inserts ajuinction at the split directory of second replicated instance and deletes the file copies in the split path. This embodiment has as an advantage that volume manager 140 knows when the volume split is successful and can insert the new junction on the replicated instances immediately.
- volume split of second replicated instance 135 is performed during the normal process of replication.
- Using the standard replication process might take more time than using volume manager 140 . However, if time is not a big concern, then it makes sense to utilize the replication process that is already in place. Second replicated instance 135 (and other replicated instances with the temporary junction), continue to operate fine, but with an extra level of delay. This step replaces the temporary junctions with junctions that point directly to the target volume.
- FIG. 1 shows DFS GUID creator 150 , file verifier 160 , subdirectory mover 165 , junction creator 155 , and junction remover 170 as being included in volume manager 140
- each of the modules interact with volume manager 140 , while being distinct from the volume manager.
- these modules can each reside on a different computer from the computer with volume manager 140 and connect to the volume manager over network 120 .
- FIG. 2 shows a file system contained on the first replicated instance and the corresponding file system copy on the second replicated instance shown in FIG. 1 .
- First replicated instance 125 includes root directory 205 .
- directory 210 “Dir_A”, file 215 “File1”, and directory 220 “Dir_B”.
- Directory 210 stores file 225 “File2” and directory 230 “Dir_C”.
- Directory 230 stores three files: file 235 “File3”, file 240 “File4” and file 245 “File5”.
- Second replicated instance 135 includes a copy of the directory tree on first replicated instance 125 .
- Second replicated instance 135 includes root directory 250 .
- root directory 250 stores three entries: directory copy 255 is a copy of “Dir_A”, file copy 260 is a copy of “File1”, and directory copy 265 is a copy of “Dir_B”.
- directory copy 255 stores file copy 270 and directory copy 275 .
- directory copy 275 stores file copy 280 “File3”, file copy 285 “File4”, and file copy 290 “File5”.
- the directory tree and directory tree copy are in sync with each other.
- a client can be updating data on either first replicated instance 125 or second replicated instance 135 .
- first replicated instance 125 For example, suppose a new file is created in the directory copy 265 . Immediately upon creation, that file might only exist on second replicated instance 135 . However, the replication process ensures that a copy of the new file is also added to corresponding directory 220 on first replicated instance 125 . The replication process also handles other file events, such as a move, delete, or modification of a file.
- second replicated instance 135 can be used to provide backup to first replicated instance 125 .
- a client might access files in the directory tree on first replicated instance 125 if that volume is available. But if computer 105 , storing first replicated instance 125 , is shut down or otherwise unavailable, then the client can access the file copies on second replicated instance 135 .
- second replicated instance 135 is used to provide data storage at a particular location.
- client computers can be configured to connect to a preferred replication instance, such as one that is geographically close to the client.
- a preferred replication instance such as one that is geographically close to the client.
- the client can select a replicated instance by pinging the different servers with the replicated instances.
- the server that responds to the ping in the least amount of time is a good candidate for client selection.
- a person skilled in the art will recognize that there are other ways a client can select a replicated instance of a volume to access.
- FIG. 3 shows entries of the volumes shown in FIG. 1 in the volume location database (VLDB).
- VLDB 145 stores DFS GUIDs along with corresponding volume names and locations. For example, entry 305 shows that first replicated instance 125 on computer 105 of FIG. 1 is assigned a DFS GUID of “17C2”. Entry 310 shows that the same DFS GUID is also assigned to second replicated instance 135 on computer 110 .
- VLDB 145 when a client requests access to a volume with the DFS GUID of “17C2”, VLDB 145 returns both first replicated instance 125 on computer 105 and second replicated instance 135 on computer 110 .
- the client selects one of the returned volumes.
- the client might select the volume that is closest to the client, or the client might select a volume by nature of it being the primary volume as described above.
- the client can also select a volume arbitrarily or based on other considerations.
- VLDB 145 returns a single volume location for the client using considerations similar to those considered by a client selecting a volume.
- VLDB 145 can also return a volume location based on load considerations using information about how many clients are currently accessing a particular instance of a volume.
- target volume 130 can still be assigned a DFS GUID. Entry 315 shows that a DFS GUID is assigned to target volume 130 on computer 105 . After the volume split is successful (i.e., all data has been copied to target volume 130 ), a junction pointing to DFS GUID “334D” at target volume 130 on computer 105 can be inserted on first replicated instance 125 . As other volumes are added to the network, these additional volumes can also be assigned DFS GUID and stored in VLDB 145 . For example, if target volume 130 is replicated, then an entry of the assignment of DFS GUID “334D” to the replicated instance of the target volume would be added to VLDB 145 .
- Each entry in VLDB 145 provides enough details for the client to access the particular volume of interest to the client. In other situations, more or less location information might be provided. For example, if there is only one volume per computer, then a client might be able to access a volume simply by knowing the computer name. Or each volume could have a unique name making identification and location simple based on the name.
- FIG. 4 shows the first replicated instance of FIG. 1 before the files in the split path are moved to the target volume.
- clients accessing data in split path 415 on other replicated instances are redirected to the split directory on first replicated instance 125 .
- temporary DFS GUID 405 “3E1A” is assigned to first replicated instance 125 .
- DFS GUID 410 “17C2” remains assigned to first replicated instance 125 .
- a symbolic link or other method can be used to redirect clients from other replicated instances to first replicated instance 125 .
- Directories and files in split path 415 are shown with dotted lines.
- the files in split path 415 are directory 210 “Dir_A”, file 225 “File2”, directory 230 “Dir_C”, file 235 “File3”, file 240 “File4”, and file 245 “File5”.
- directory 210 is the split directory as it is the root directory of split path 415 .
- FIG. 5 shows the temporary DFS GUID of FIG. 4 added to the VLDB.
- entry 505 is added to VLDB 145 .
- Entry 505 shows that DFS GUID “3E1A” has been assigned to first replicated instance 125 on computer 105 .
- VLDB 145 receives a request for a volume with a DFS GUID of “17C2”
- VLDB 145 identifies two volumes that are assigned to that DFS GUID: first replicated instance 125 and second replicated instance 135 .
- the client can then access one of these volumes. If the client selects first replicated instance 125 to access, the client accesses the volume as usual. If the client selects second replicated instance 135 , then if the client accesses Dir_A, the client encounters the inserted junction and redirects the client to first replicated instance 125 . Note that client access of files on second replicated instance 135 that are not in the Dir_A split path are handled without being redirected to first replicated instance 125 .
- FIG. 6 shows a junction pointing to the split directory of the first replicated instance inserted at the split directory on the second replicated instance of FIG. 1 .
- the client accesses split directory “Dir_A” on second replicated instance 135 .
- Junction 605 directs the client to Dir_A on the replicated instance that is assigned to the DFS GUID “3E1A”. Because the DFS GUID “3E1A” is assigned to first replicated instance 125 , clients access this volume instance.
- junction 605 After junction 605 is inserted at split directory 255 , file verifier 160 verifies that each file in split path 610 is closed. If all files are closed when junction 605 is inserted on second replicated instance 135 , then file verifier 160 can report this immediately. Recall that junction 605 serves to redirect clients to Dir_A on first replicated instance 125 , thus copies of files that are closed when junction 605 is inserted remain closed until junction 605 is removed.
- file verifier 160 waits until the file copy is closed and then notifies volume manager 140 once all file copies are closed. For example, suppose file copy 270 “File2” and file copy 285 “File4” are open when junction 605 is added to the volume. Users could be simply accessing the file copies or making changes to the file copies. Once the user is finished accessing file copy 270 , then file verifier 160 notices that the file copy is now closed. If the user tries to access the file copy again, junction 605 redirects the user to file 225 on first replicated instance 125 rather than allowing the user to access file copy 270 as done earlier.
- FIG. 7 shows the target volume and first replicated instance of FIG. 1 after the files in the split path are moved from the first replicated instance to the target volume.
- Target volume 130 now includes root directory 705 and the files in the split path: file 715 “File2”, directory 720 “Dir_C”, file 725 “File3”, file 730 “File4”, and file 735 “File5”.
- First replicated instance 125 no longer includes corresponding versions of the files from the split path. Instead, root directory 205 includes junction 740 named “Dir_A” (the split directory that was previously stored in root directory 205 of first replicated instance 125 ). In an embodiment of the invention, junction 740 appears to a client as if it is directory 210 “Dir_A” that had been stored in root directory 205 . Junction 740 includes the DFS GUID “334D” identifying the location of the moved files. When a client sees junction 740 on first replicated instance 125 , the client can look up the DFS GUID identified in the junction to determine that target volume 130 is assigned the appropriate DFS GUID.
- a volume split is complete when all files in the split path are moved from first replicated instance 125 to target volume 130 and any changes occurring afterwards are reflected in the files on the target volume.
- temporary DFS GUID 405 is unassigned from first replicated instance 125 (as indicated by the dashed line). Temporary DFS GUID 405 can then be removed from the VLDB, and the VLDB returns to containing the entries shown in FIG. 3 .
- FIG. 8 shows the second replicated instance of FIG. 1 after the split directory is replaced with a junction to the target volume.
- second replicated instance 135 includes root directory 250 storing file copy 260 “File1” and directory copy 265 “Dir_B”.
- second replicated instance 135 also includes junction 805 (named “Dir_A”) redirecting clients to target volume 130 , and the file copies from the split path are removed from replicated instance of the first replicated instance.
- junction 805 has the appearance of being Dir_A.
- volume manager 140 replaces the split directory with junction 805 after the split operation is successful.
- the standard replication process synchronizes second replicated instance 135 with first replicated instance 125 according the standard replication process. For example, if it is important to have the volume split reflected in second replicated instance 135 as soon as possible (for maximum availability and to avoid the extra overhead of continuing to go through temporary junction 605 ), then volume manager 140 can create junction 805 immediately after the volume split of first replicated instance 125 is complete. If it is acceptable for a period of time to occur before the propagation, then the split can be replicated using standard replication techniques.
- FIGS. 9A-9B show a flowchart of the process of splitting the replicated instances of the volume shown in FIG. 1 .
- both source volume and replicated instance refer to replicated instances of the same volume.
- the source volume only differs from the other replicated instances in that the source volume is the particular replicated instance where the volume split occurs.
- the volume manager assigns a temporary DFS GUID to the source volume.
- the volume manager stores the temporary DFS GUID in the VLDB with the location of the source volume including the location of the source volume.
- the volume manager inserts a junction at the split directory on the replicated instance. As previously discussed with reference to FIG. 6 , the junction is used to direct client requests for files in the split path in the replicated instance to the split path of the source volume, in effect taking the split path of the replicated instance off-line. In other words, while the volume split is in progress, the benefits of using replicated volumes are somewhat suspended, and client requests for files in the split path go to the source volume.
- client requests for files that are not in the split path stay at the replicated instance, maximally preserving the benefits of volume replication.
- the volume is able to be split while allowing clients to access the data on the volume. This is a benefit to users with a preference towards data access.
- the volume manager After the volume manager inserts the junction in the replicated instance, at step 920 the volume manager verifies that each file in the split path on the replicated instance is closed. Note that when the junction is inserted in the replicated instance of the source volume, it is possible that a client is in the process of accessing a file on the split path.
- steps 915 and 920 if there is another replicated instance, then the process returns to steps 915 and 920 .
- steps 915 and 920 are temporarily redirected to the source volume (as indicated by step 915 ), and each file in the split path of the replicated instances are closed (as indicated by step 920 ), then the source volume can be split. Note that although FIG. 9 shows steps 915 and 920 occurring for a single volume instance at a time, in another embodiment of the invention, steps 915 and 920 are performed in parallel for each volume instance.
- the volume manager copies the files in the split path on the source volume to the target volume while allowing clients to access to the files.
- the volume manager replaces the split directory with a junction to the target volume.
- the junction includes the DFS GUID of the target volume.
- the volume manager deletes the moved subdirectory from the source volume.
- the deletion can be a background task that can be performed any time after the junction to the target volume is inserted on source volume.
- step 940 can also be performed in parallel with step 945 .
- the volume manager replaces the temporary junction to the source volume on the replicated instance with a junction to the target volume, and clients access the files on target volume.
- step 950 the files in the split path on the replicated instance are deleted. Note that although step 950 is shown as occurring after step 945 , in an embodiment of the invention step 950 can occur any time after step 920 . At decision block 955 , if there are additional replicated instances of the volume, then the process returns to steps 945 and 950 . In an embodiment of the invention, steps 945 and 950 can be performed at the same time for each replicated instance of the source volume.
- steps 945 and 950 are handled by the volume manager, which can insert a junction to the target volume and remove the copies of the moved files from the replicated instance(s) as soon as the volume split is completed on the source volume.
- the volume manager knows when the volume split is successful, and can propagate the split immediately.
- propagation of the volume split can be achieved by using the normal replication process.
- steps 945 and 950 are eliminated as the replication process handles the replacement of the temporary junction and the deletion of files.
- This embodiment does not require any further action by the volume manager, although using the normal replication process might mean that the propagation occurs on a replication schedule, and the split is not necessarily replicated immediately.
- step 960 the volume manager next removes the temporary DFS GUID from the VLDB. This step is performed after all other steps have completed successfully.
- the machine includes a system bus to which is attached processors, memory, e.g., random access memory (RAM), read-only memory (ROM), or other state preserving medium, storage devices, a video interface, and input/output interface ports.
- the machine may be controlled, at least in part, by input from conventional input devices, such as keyboards, mice, etc., as well as by directives received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signal.
- VR virtual reality
- the term “machine” is intended to broadly encompass a single machine, or a system of communicatively coupled machines or devices operating together. Exemplary machines include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, telephones, tablets, etc., as well as transportation devices, such as private or public transportation, e.g., automobiles, trains, cabs, etc.
- the machine may include embedded controllers, such as programmable or non-programmable logic devices or arrays, Application Specific Integrated Circuits, embedded computers, smart cards, and the like.
- the machine may utilize one or more connections to one or more remote machines, such as through a network interface, modem, or other communicative coupling.
- Machines may be interconnected by way of a physical and/or logical network, such as an intranet, the Internet, local area networks, wide area networks, etc.
- network communication may utilize various wired and/or wireless short range or long range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 802.11, Bluetooth, optical, infrared, cable, laser, etc.
- RF radio frequency
- IEEE Institute of Electrical and Electronics Engineers
- Associated data may be stored in, for example, the volatile and/or non-volatile memory, e.g., RAM, ROM, etc., or in other storage devices and their associated storage media, including hard-drives, floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, biological storage, etc.
- Associated data may be delivered over transmission environments, including the physical and/or logical network, in the form of packets, serial data, parallel data, propagated signals, etc., and may be used in a compressed or encrypted format.
- Associated data may be used in a distributed environment, and stored locally and/or remotely for machine access.
Abstract
Description
- This application is related to co-pending, commonly assigned, U.S. patent application Ser. No. 10/413,957, titled “METHOD AND APPARATUS FOR MOVING DATA BETWEEN STORAGE DEVICES,” filed Apr. 14, 2003 by the same inventor, and is hereby incorporated by reference.
- This invention relates to moving data between storage devices in a computer system, and more particularly to moving data on a replicated storage device.
- Today's networked environment enables data storage to span multiple data volumes and multiple computers. A distributed file system (DFS) is one where multiple file systems, each residing on a different storage volume, are connected to one another. The different storage volumes can be included in the same computer or in different computers connected together using a network. The file systems on the different storage volumes could have once been part of a single file system on a single storage volume. For example, when an organization is just starting out, the data storage requirements for that organization might be modest, and the organization is able to store all data on a single volume. After a while, as the organization grows, the original volume reaches its maximum storage capacity. Instead of simply starting a new volume from scratch, the organization may wish to divide the volume, moving a subdirectory tree from the volume to the new volume, while appearing to the client as though only a single volume is in use.
- While splitting a volume makes it easy for organization members to access data as they have always done, performing the volume split can be inconvenient for the organization members. As data is being moved to a new location, that data must first be taken off-line and made unavailable to users to prevent inconsistencies in the data.
- In addition to using DFS to manage data storage, a system administrator can also use volume replication to replicate one or more of the volumes. Volume replication allows a file system that is on one volume to be copied and made available to clients on one or more other volumes; each volume is typically called a replicated instance of the volume. Volume replication has several advantages. One advantage is that one replicated instance can act as a data backup in the event that another replicated instance of the same volume goes down. Another advantage of volume replication is that data can be moved closer to where the user needs it, thus potentially providing performance improvements in accessing and downloading the data.
- Using DFS in conjunction with volume replication introduces new complications to splitting a replicated volume. When splitting a replicated volume, each replicated instance of the volume must be taken off-line before moving the desired subdirectory tree to the new volume. Taking each replicated instance off-line removes some the advantages that volume replication specifically provides. With each replicated instance off-line, the volume is not available.
- Another approach might be to take each volume off-line only as the volume split is being performed at each volume. This approach has the advantage that users can access data on one of the volumes: either the primary volume or the replicated instance of the primary volume. But if a replication method is used where there is a lag time between volume synchronization, then there is a possibility that the volume instances will have inconsistent data after the volume split occurs.
- Accordingly, a need exists for a technique to split a replicated volume, while maintaining user access to the files being moved.
- At least two replicated instances of a source volume are split while allowing clients to access data moved during the split. Clients are redirected to the first replicated instance of the source volume. The first replicated instance is split by first moving files in a split path from the first replicated instance to the target volume. Then, after the files in the split path have been successfully moved to the target volume, a junction is inserted at the split directory to redirect clients to the target volume. After the first replicated instance is split, a second junction replaces the split path on the replicated instance of the first replicated instance.
- 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.
-
FIG. 1 shows a computer system configured to split a replicated volume while allowing clients to access the files that are moved from the volume, according to an embodiment of the invention. -
FIG. 2 shows a file system contained on the first replicated instance and the corresponding file system copy on the second replicated instance shown inFIG. 1 . -
FIG. 3 shows entries of the volumes shown inFIG. 1 in the volume location database (VLDB). -
FIG. 4 shows the first replicated instance ofFIG. 1 before the files in the split path are moved to the target volume. -
FIG. 5 shows the temporary DFS GUID ofFIG. 4 added to the VLDB. -
FIG. 6 shows a junction pointing to the split directory of the first replicated instance inserted at the split directory on the second replicated instance ofFIG. 1 . -
FIG. 7 shows the target volume and first replicated instance ofFIG. 1 after the contents of the split path are moved from the first replicated instance to the target volume. -
FIG. 8 shows the second replicated instance ofFIG. 1 after the subdirectory tree is replaced with a junction to the target volume. -
FIGS. 9A-9B show a flowchart of the process of splitting the replicated volume shown inFIG. 1 . - U.S. patent application Ser. No. 10/413,957, titled “METHOD AND APPARATUS FOR MOVING DATA BETWEEN STORAGE DEVICES,” (herein referred to as “the Moving Data application”), filed Apr. 14, 2003 by the same inventor, and hereby incorporated by reference, describes a means for splitting data off one volume and moving it to another storage volume, while allowing clients to access the data on the storage volume during the move. The technique described in the Moving Data application applies when there is a single instance of the source volume. When there are replicated instances of the volume, then changes made to a copy of a file on a replicated instance might not be reflected in the files on the new volume after the volume is split. U.S. patent application Ser. No. 10/283,960, title “AN APPARATUS FOR POLICY BASED STORAGE OF FILE DATA AND META-DATA CHANGES OVER TIME”, filed Oct. 29, 2002, now pending and incorporated by reference herein, describes a system and method for managing events.
-
FIG. 1 shows a computer system configured to split a replicated volume while allowing clients to access the files that are moved from the volume, according to an embodiment of the invention.Computer 105,computer 110, andcomputer 115 connect to one another usingnetwork 120.Computers Computers FIG. 1 . Note that althoughFIG. 1 shows three computers, a person skilled in the art will recognize that any number of computers can be used. -
FIG. 1 shows two instances of a replicated volume. Any number of replicated instances can be used.Computer 105 includes first replicatedinstance 125 andtarget volume 130.Computer 110 includes second replicatedinstance 135. In an embodiment of the invention, first replicatedinstance 125 and second replicatedinstance 135 are replicated instances of the same volume. First replicatedinstance 125 and second replicatedinstance 135 include file systems that are accessed by client computers acrossnetwork 120. The volumes are stored on storage media and can span multiple physical storage devices if needed (for example, a storage area network (SAN)). - Not shown in
FIG. 1 are client computers that interact withcomputers - In an embodiment of the invention, because first replicated
instance 125 and second replicatedinstance 135 contain copies of the same files, client computers can access either one ofcomputer 105 orcomputer 110. Considerations by the client computer as to which computer to connect to are addressed below with reference toFIG. 2 . - Client computers connect to
computers network 120.Network 120 can 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). - In an embodimnent of the invention, a volume is split when some files are moved from the volume to a new volume while other files are retained at the original volume. Typically the files in a directory or subdirectory on the original volume are moved to the new volume. A split directory refers to the directory or subdirectory identifying where the volume split occurs. The files and directories nested in the split directory make up a subdirectory tree referred to as a split path. Directories and files that are not in the split path remain on the original volume after the volume split.
- During the split operation, client computers can access files on the replicated volume, including files being moved to the new volume. 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. During the volume split a list of logged files is maintained so that the new volume can be updated with the modified files.
-
FIG. 1 showstarget volume 130 included incomputer 105.Target volume 130 is the destination volume for data moved from the replicated volume as first replicatedinstance 125 is split. Althoughtarget volume 130 is shown as being part ofcomputer 105, a person skilled in the art will recognize thattarget volume 130 can be included in another computer connected tocomputer 105 overnetwork 120. In addition,target volume 130 can itself be replicated with any number of instances. Iftarget volume 130 is replicated, the replication level and location of the replicated instances are specified whentarget volume 130 is created. This makes no difference to the split operation, astarget volume 130 represents the instance where the files are moved. - Not shown in
FIG. 1 is a replication manager responsible for maintaining consistency between replicated instances of a volume, such as first replicatedinstance 125 and second replicatedinstance 135. Also, iftarget volume 130 is replicated, the replication manager is responsible for keeping the other instances oftarget volume 130 in sync. - In an embodiment of the invention,
computer 105 includesvolume manager 140.Volume manager 140 performs the volume split of first replicatedinstance 125. For example, a system administrator can send a request tovolume manager 140 identifying a split path on first replicatedinstance 125 to be moved to targetvolume 130. The Moving Data application describes howvolume manager 140 can split first replicatedinstance 125 while allowing clients to access the moved file during the volume split. In addition,computer 110 includesvolume manager 175 that can split second replicatedinstance 135. -
Volume manager 140 andvolume manager 175 interface with volume location database (VLDB) 145 stored oncomputer 115. In an embodiment of the invention,VLDB 145 associates volume names with a distributed file system (DFS) globally unique identifier (GUID) and the physical location of the volumes.VLDB 145 is accessible from most of the computers in the network. A client computer can access a particular volume instance by looking up the volume inVLDB 145 to resolve the physical location of the volume.VLDB 145 is described in greater detail below with reference toFIGS. 3 and 5 . - In an embodiment of the invention, clients seeking access to files in the split path of second replicated
instance 135 are redirected to first replicatedinstance 125 as first replicatedinstance 125 is being split. If there are additional replicated instances of the volume, the split paths of these instances are also redirected to first replicatedinstance 125. In an embodiment of the invention, a junction identifying first replicatedinstance 125 is inserted in the split path of second replicatedinstance 135. The use of a junction is discussed in greater detail below with reference toFIG. 6 . In another embodiment, a symbolic link is used to redirect clients. -
Volume manager 140 includesDFS GUID creator 150,junction creator 155, andfile verifier 160 to insert a junction to redirect client access to files on the split path of second replicatedinstance 135. Although not shown inFIG. 1 ,volume manager 175 also includes these elements.DFS GUID creator 150 creates a temporary DFS GUID to assign to first replicatedinstance 125. In creating a temporary DFS GUID,DFS GUID creator 150 looks for a unique identifier to be assigned to first replicatedinstance 125. Then, if a client identifies a junction with the temporary DFS GUID, the client can look up the temporary DFS GUID inVLDB # 145 and identify first replicatedinstance 125 as the appropriate volume for redirection. If temporary DFS GUID is not unique, then the client might redirect to another volume in error. - After
DFS GUID creator 150 assigns a temporary DFS GUID to first replicatedinstance 125,junction creator 155 inserts a temporary junction at the split directory of second replicatedinstance 135. A junction acts as a “link” between volumes, connecting two volumes using a DFS GUID in the junction to point from one volume to another volume. When encountering a junction, the client represents the junction as a subdirectory to the end user. In an embodiment of the invention, the inserted junction includes the temporary DFS GUID that is assigned to first replicatedinstance 125. As the client encounters the junction on second replicatedinstance 135, the client looks up the temporary DFS GUID inVLDB 145 to identify the name and location of the volume assigned that DFS GUID. Inserting a junction with the temporary DFS GUID at the split directory of second replicatedinstance 135 in effect takes the split path of second replicatedinstance 135 off-line. Note that as the junction is in the split path of second replicatedinstance 135, the benefits of volume replication are temporarily suspended for the files in the split path, with only first replicatedinstance 125 accessible for those files. Finally, when inserting the junction with the temporary DFS GUID at the split path of a replicated instance other than the instance where the volume split occurs,volume manager 140 notifies the replication manager to not replicate the temporary junction. - In an embodiment of the invention,
file verifier 160 verifies that each file copy in the split path of second replicatedinstance 135 is closed.File verifier 160 is discussed in greater detail below with reference toFIG. 6 . Oncefile verifier 160 verifies that all files in the split path are closed, first replicatedinstance 125 is temporarily the sole volume available for client access for files in the split path.Volume manager 140 then splits first replicatedinstance 125. In an embodiment of the invention,subdirectory mover 165 performs the split of first replicatedinstance 125 while clients can access and modify files on first replicatedinstance 125. - After
volume manager 140 has successfully split first replicatedinstance 125,junction remover 170 removes the temporary junction from second replicatedinstance 135.Volume manager 140 then inserts ajuinction at the split directory of second replicated instance and deletes the file copies in the split path. This embodiment has as an advantage thatvolume manager 140 knows when the volume split is successful and can insert the new junction on the replicated instances immediately. - In an embodiment of the invention, volume split of second replicated
instance 135 is performed during the normal process of replication. Using the standard replication process might take more time than usingvolume manager 140. However, if time is not a big concern, then it makes sense to utilize the replication process that is already in place. Second replicated instance 135 (and other replicated instances with the temporary junction), continue to operate fine, but with an extra level of delay. This step replaces the temporary junctions with junctions that point directly to the target volume. - Finally, although
FIG. 1 showsDFS GUID creator 150,file verifier 160,subdirectory mover 165,junction creator 155, andjunction remover 170 as being included involume manager 140, in another embodiment, each of the modules interact withvolume manager 140, while being distinct from the volume manager. In addition, these modules can each reside on a different computer from the computer withvolume manager 140 and connect to the volume manager overnetwork 120. -
FIG. 2 shows a file system contained on the first replicated instance and the corresponding file system copy on the second replicated instance shown inFIG. 1 . First replicatedinstance 125 includesroot directory 205. At the root level aredirectory 210 “Dir_A”, file 215 “File1”, anddirectory 220 “Dir_B”.Directory 210 stores file 225 “File2” anddirectory 230 “Dir_C”.Directory 230, in turn, stores three files: file 235 “File3”, file 240 “File4” and file 245 “File5”. - Second replicated
instance 135 includes a copy of the directory tree on first replicatedinstance 125. Second replicatedinstance 135 includesroot directory 250. Likeroot directory 205 on first replicatedinstance 125,root directory 250 stores three entries:directory copy 255 is a copy of “Dir_A”,file copy 260 is a copy of “File1”, anddirectory copy 265 is a copy of “Dir_B”. In turn,directory copy 255 stores filecopy 270 anddirectory copy 275. Finally,directory copy 275 stores filecopy 280 “File3”,file copy 285 “File4”, andfile copy 290 “File5”. - In
FIG. 2 , the directory tree and directory tree copy are in sync with each other. At other instances in time, a client can be updating data on either first replicatedinstance 125 or second replicatedinstance 135. For example, suppose a new file is created in thedirectory copy 265. Immediately upon creation, that file might only exist on second replicatedinstance 135. However, the replication process ensures that a copy of the new file is also added tocorresponding directory 220 on first replicatedinstance 125. The replication process also handles other file events, such as a move, delete, or modification of a file. - In an embodiment of the invention, second replicated
instance 135 can be used to provide backup to first replicatedinstance 125. In this embodiment, a client might access files in the directory tree on first replicatedinstance 125 if that volume is available. But ifcomputer 105, storing first replicatedinstance 125, is shut down or otherwise unavailable, then the client can access the file copies on second replicatedinstance 135. - In another embodiment of the invention, second replicated
instance 135 is used to provide data storage at a particular location. Consider an organization with an office in Utah and an office in Massachusetts, and volumes in computers at the two different locations. The users in Utah might access data on the replicated instance in Utah, while the users in Massachusetts might access data on the geographically closer replicated instance of the volume. In an embodiment of the invention, client computers can be configured to connect to a preferred replication instance, such as one that is geographically close to the client. By enabling users to access data on a volume close to the user, time spent accessing and downloading the data can be improved. After the user has made changes to the data, then the replication process ensures that the data on the one volume is synchronized with the data on the other volume, with little inconvenience to the user. - In yet another embodiment of the invention, the client can select a replicated instance by pinging the different servers with the replicated instances. The server that responds to the ping in the least amount of time is a good candidate for client selection. A person skilled in the art will recognize that there are other ways a client can select a replicated instance of a volume to access.
-
FIG. 3 shows entries of the volumes shown inFIG. 1 in the volume location database (VLDB).VLDB 145 stores DFS GUIDs along with corresponding volume names and locations. For example,entry 305 shows that first replicatedinstance 125 oncomputer 105 ofFIG. 1 is assigned a DFS GUID of “17C2”.Entry 310 shows that the same DFS GUID is also assigned to second replicatedinstance 135 oncomputer 110. In an embodiment of the invention, when a client requests access to a volume with the DFS GUID of “17C2”,VLDB 145 returns both first replicatedinstance 125 oncomputer 105 and second replicatedinstance 135 oncomputer 110. The client then selects one of the returned volumes. The client might select the volume that is closest to the client, or the client might select a volume by nature of it being the primary volume as described above. The client can also select a volume arbitrarily or based on other considerations. - In another embodiment of the invention,
VLDB 145 returns a single volume location for the client using considerations similar to those considered by a client selecting a volume. In addition,VLDB 145 can also return a volume location based on load considerations using information about how many clients are currently accessing a particular instance of a volume. - Although
target volume 130 initially stores no data,target volume 130 can still be assigned a DFS GUID.Entry 315 shows that a DFS GUID is assigned to targetvolume 130 oncomputer 105. After the volume split is successful (i.e., all data has been copied to target volume 130), a junction pointing to DFS GUID “334D” attarget volume 130 oncomputer 105 can be inserted on first replicatedinstance 125. As other volumes are added to the network, these additional volumes can also be assigned DFS GUID and stored inVLDB 145. For example, iftarget volume 130 is replicated, then an entry of the assignment of DFS GUID “334D” to the replicated instance of the target volume would be added toVLDB 145. - Each entry in
VLDB 145 provides enough details for the client to access the particular volume of interest to the client. In other situations, more or less location information might be provided. For example, if there is only one volume per computer, then a client might be able to access a volume simply by knowing the computer name. Or each volume could have a unique name making identification and location simple based on the name. -
FIG. 4 shows the first replicated instance ofFIG. 1 before the files in the split path are moved to the target volume. In an embodiment of the invention, before splitting first replicatedinstance 125, clients accessing data insplit path 415 on other replicated instances (such as second replicated instance 135) are redirected to the split directory on first replicatedinstance 125. In an embodiment of the invention, to minimize the inconvenience to clients as well as preserve data integrity,temporary DFS GUID 405 “3E1A” is assigned to first replicatedinstance 125. Note thatDFS GUID 410 “17C2” remains assigned to first replicatedinstance 125. In another embodiment of the invention, a symbolic link or other method can be used to redirect clients from other replicated instances to first replicatedinstance 125. - Directories and files in
split path 415 are shown with dotted lines. The files insplit path 415 aredirectory 210 “Dir_A”, file 225 “File2”,directory 230 “Dir_C”, file 235 “File3”, file 240 “File4”, and file 245 “File5”. In addition,directory 210 is the split directory as it is the root directory ofsplit path 415. -
FIG. 5 shows the temporary DFS GUID ofFIG. 4 added to the VLDB. Aftervolume manager 140 assignstemporary DFS GUID 405 ofFIG. 10 to first replicatedinstance 125,entry 505 is added toVLDB 145.Entry 505 shows that DFS GUID “3E1A” has been assigned to first replicatedinstance 125 oncomputer 105. By creatingentry 505 with the assignment oftemporary DFS GUID 405 to first replicatedinstance 125 oncomputer 105, it is possible to temporarily redirect clients attempting to access second replicatedinstance 135 to first replicatedinstance 125. - For example, if
VLDB 145 receives a request for a volume with a DFS GUID of “17C2”,VLDB 145 identifies two volumes that are assigned to that DFS GUID: first replicatedinstance 125 and second replicatedinstance 135. As discussed above with reference toFIG. 4 , the client can then access one of these volumes. If the client selects first replicatedinstance 125 to access, the client accesses the volume as usual. If the client selects second replicatedinstance 135, then if the client accesses Dir_A, the client encounters the inserted junction and redirects the client to first replicatedinstance 125. Note that client access of files on second replicatedinstance 135 that are not in the Dir_A split path are handled without being redirected to first replicatedinstance 125. -
FIG. 6 shows a junction pointing to the split directory of the first replicated instance inserted at the split directory on the second replicated instance ofFIG. 1 . In an embodiment of the invention, when a client accesses split directory “Dir_A” on second replicatedinstance 135, the client encountersjunction 605.Junction 605 directs the client to Dir_A on the replicated instance that is assigned to the DFS GUID “3E1A”. Because the DFS GUID “3E1A” is assigned to first replicatedinstance 125, clients access this volume instance. - After
junction 605 is inserted atsplit directory 255,file verifier 160 verifies that each file insplit path 610 is closed. If all files are closed whenjunction 605 is inserted on second replicatedinstance 135, then fileverifier 160 can report this immediately. Recall thatjunction 605 serves to redirect clients to Dir_A on first replicatedinstance 125, thus copies of files that are closed whenjunction 605 is inserted remain closed untiljunction 605 is removed. - However, if any copies of files in
split path 610 are open whenjunction 605 is inserted in the volume,file verifier 160 waits until the file copy is closed and then notifiesvolume manager 140 once all file copies are closed. For example, supposefile copy 270 “File2” andfile copy 285 “File4” are open whenjunction 605 is added to the volume. Users could be simply accessing the file copies or making changes to the file copies. Once the user is finished accessingfile copy 270, then file verifier 160 notices that the file copy is now closed. If the user tries to access the file copy again,junction 605 redirects the user to file 225 on first replicatedinstance 125 rather than allowing the user to accessfile copy 270 as done earlier. - Once each file in
split path 610 is closed,file verifier 160 notifiesvolume manager 140 that first replicatedinstance 125 can now be split. In an embodiment of the invention, first replicatedinstance 125 is split while permitting users to access the files on first replicatedinstance 125. The volume split can be performed as described in the Moving Data application.FIG. 7 shows the target volume and first replicated instance ofFIG. 1 after the files in the split path are moved from the first replicated instance to the target volume.Target volume 130 now includesroot directory 705 and the files in the split path: file 715 “File2”,directory 720 “Dir_C”, file 725 “File3”, file 730 “File4”, and file 735 “File5”. - First replicated
instance 125 no longer includes corresponding versions of the files from the split path. Instead,root directory 205 includesjunction 740 named “Dir_A” (the split directory that was previously stored inroot directory 205 of first replicated instance 125). In an embodiment of the invention,junction 740 appears to a client as if it isdirectory 210 “Dir_A” that had been stored inroot directory 205.Junction 740 includes the DFS GUID “334D” identifying the location of the moved files. When a client seesjunction 740 on first replicatedinstance 125, the client can look up the DFS GUID identified in the junction to determine thattarget volume 130 is assigned the appropriate DFS GUID. - A volume split is complete when all files in the split path are moved from first replicated
instance 125 to targetvolume 130 and any changes occurring afterwards are reflected in the files on the target volume. In an embodiment of the invention, aftervolume manager 140 successfully performs the volume split,temporary DFS GUID 405 is unassigned from first replicated instance 125 (as indicated by the dashed line).Temporary DFS GUID 405 can then be removed from the VLDB, and the VLDB returns to containing the entries shown inFIG. 3 . -
FIG. 8 shows the second replicated instance ofFIG. 1 after the split directory is replaced with a junction to the target volume. Just as prior to the volume split, second replicatedinstance 135 includesroot directory 250storing file copy 260 “File1” anddirectory copy 265 “Dir_B”. In addition, second replicatedinstance 135 also includes junction 805 (named “Dir_A”) redirecting clients to targetvolume 130, and the file copies from the split path are removed from replicated instance of the first replicated instance. To users,junction 805 has the appearance of being Dir_A. - In an embodiment of the invention,
volume manager 140 replaces the split directory withjunction 805 after the split operation is successful. In another embodiment of the invention, the standard replication process synchronizes second replicatedinstance 135 with first replicatedinstance 125 according the standard replication process. For example, if it is important to have the volume split reflected in second replicatedinstance 135 as soon as possible (for maximum availability and to avoid the extra overhead of continuing to go through temporary junction 605), thenvolume manager 140 can createjunction 805 immediately after the volume split of first replicatedinstance 125 is complete. If it is acceptable for a period of time to occur before the propagation, then the split can be replicated using standard replication techniques. -
FIGS. 9A-9B show a flowchart of the process of splitting the replicated instances of the volume shown inFIG. 1 . In this discussion, both source volume and replicated instance refer to replicated instances of the same volume. The source volume only differs from the other replicated instances in that the source volume is the particular replicated instance where the volume split occurs. - At
step 905, the volume manager assigns a temporary DFS GUID to the source volume. Atstep 910, the volume manager stores the temporary DFS GUID in the VLDB with the location of the source volume including the location of the source volume. Atstep 915, the volume manager inserts a junction at the split directory on the replicated instance. As previously discussed with reference toFIG. 6 , the junction is used to direct client requests for files in the split path in the replicated instance to the split path of the source volume, in effect taking the split path of the replicated instance off-line. In other words, while the volume split is in progress, the benefits of using replicated volumes are somewhat suspended, and client requests for files in the split path go to the source volume. However, client requests for files that are not in the split path stay at the replicated instance, maximally preserving the benefits of volume replication. But, by directing client requests for files in the split path to the single volume, the volume is able to be split while allowing clients to access the data on the volume. This is a benefit to users with a preference towards data access. - After the volume manager inserts the junction in the replicated instance, at
step 920 the volume manager verifies that each file in the split path on the replicated instance is closed. Note that when the junction is inserted in the replicated instance of the source volume, it is possible that a client is in the process of accessing a file on the split path. - At
decision block 925, if there is another replicated instance, then the process returns tosteps FIG. 9 showssteps - At
step 930, the volume manager copies the files in the split path on the source volume to the target volume while allowing clients to access to the files. After the files in the split path are successfully moved from the source volume to the target volume, atstep 935 the volume manager replaces the split directory with a junction to the target volume. In an embodiment of the invention, the junction includes the DFS GUID of the target volume. As a client computer requests a file in the split path, the client encounters the junction including the DFS GUID. The client then looks up the DFS GUID in the VLDB, and identifies the location of the target volume. Then the client connects to the target volume. - At step 940 (
FIG. 9B ), the volume manager deletes the moved subdirectory from the source volume. The deletion can be a background task that can be performed any time after the junction to the target volume is inserted on source volume. In an embodiment of theinvention step 940 can also be performed in parallel withstep 945. Atstep 945, the volume manager replaces the temporary junction to the source volume on the replicated instance with a junction to the target volume, and clients access the files on target volume. - At
step 950, the files in the split path on the replicated instance are deleted. Note that althoughstep 950 is shown as occurring afterstep 945, in an embodiment of theinvention step 950 can occur any time afterstep 920. Atdecision block 955, if there are additional replicated instances of the volume, then the process returns tosteps - In one embodiment of the invention, steps 945 and 950 are handled by the volume manager, which can insert a junction to the target volume and remove the copies of the moved files from the replicated instance(s) as soon as the volume split is completed on the source volume. This embodiment has as an advantage that the volume manager knows when the volume split is successful, and can propagate the split immediately.
- In another embodiment of the invention, propagation of the volume split can be achieved by using the normal replication process. In this embodiment steps 945 and 950 are eliminated as the replication process handles the replacement of the temporary junction and the deletion of files. This embodiment does not require any further action by the volume manager, although using the normal replication process might mean that the propagation occurs on a replication schedule, and the split is not necessarily replicated immediately.
- Finally, at
step 960, the volume manager next removes the temporary DFS GUID from the VLDB. This step is performed after all other steps have completed successfully. - The following discussion is intended to provide a brief, general description of a suitable machine in which certain aspects of the invention may be implemented. Typically, the machine includes a system bus to which is attached processors, memory, e.g., random access memory (RAM), read-only memory (ROM), or other state preserving medium, storage devices, a video interface, and input/output interface ports. The machine may be controlled, at least in part, by input from conventional input devices, such as keyboards, mice, etc., as well as by directives received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signal. As used herein, the term “machine” is intended to broadly encompass a single machine, or a system of communicatively coupled machines or devices operating together. Exemplary machines include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, telephones, tablets, etc., as well as transportation devices, such as private or public transportation, e.g., automobiles, trains, cabs, etc.
- The machine may include embedded controllers, such as programmable or non-programmable logic devices or arrays, Application Specific Integrated Circuits, embedded computers, smart cards, and the like. The machine may utilize one or more connections to one or more remote machines, such as through a network interface, modem, or other communicative coupling. Machines may be interconnected by way of a physical and/or logical network, such as an intranet, the Internet, local area networks, wide area networks, etc. One skilled in the art will appreciate that network communication may utilize various wired and/or wireless short range or long range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 802.11, Bluetooth, optical, infrared, cable, laser, etc.
- The invention may be described by reference to or in conjunction with associated data including functions, procedures, data structures, application programs, etc. which when accessed by a machine results in the machine performing tasks or defining abstract data types or low-level hardware contexts. Associated data may be stored in, for example, the volatile and/or non-volatile memory, e.g., RAM, ROM, etc., or in other storage devices and their associated storage media, including hard-drives, floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, biological storage, etc. Associated data may be delivered over transmission environments, including the physical and/or logical network, in the form of packets, serial data, parallel data, propagated signals, etc., and may be used in a compressed or encrypted format. Associated data may be used in a distributed environment, and stored locally and/or remotely for machine access.
- Having described and illustrated the principles of the invention with reference to illustrated embodiments, it will be recognized that the illustrated embodiments may be modified in arrangement and detail without departing from such principles. And although the foregoing discussion has focused on particular embodiments and examples, other configurations are contemplated. In particular, even though expressions such as “according to an embodiment of the invention” or the like are used herein, these phrases are meant to generally reference embodiment possibilities, and are not intended to limit the invention to particular embodiment configurations. As used herein, these terms may reference the same or different embodiments that are combinable into other embodiments.
- Consequently, in view of the wide variety of permutations to the embodiments described herein, this detailed description and accompanying material is intended to be illustrative only, and should not be taken as limiting the scope of the invention. What is claimed as the invention, therefore, is all such modifications as may come within the scope and spirit of the following claims and equivalents thereto.
Claims (24)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/555,105 US7805401B2 (en) | 2003-04-14 | 2006-10-31 | Method and apparatus for splitting a replicated volume |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/413,957 US7281014B2 (en) | 2003-04-14 | 2003-04-14 | Method and apparatus for moving data between storage devices |
US11/555,105 US7805401B2 (en) | 2003-04-14 | 2006-10-31 | Method and apparatus for splitting a replicated volume |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/413,957 Continuation-In-Part US7281014B2 (en) | 2003-04-14 | 2003-04-14 | Method and apparatus for moving data between storage devices |
Publications (3)
Publication Number | Publication Date |
---|---|
US20080104132A1 true US20080104132A1 (en) | 2008-05-01 |
US20090119344A9 US20090119344A9 (en) | 2009-05-07 |
US7805401B2 US7805401B2 (en) | 2010-09-28 |
Family
ID=39331629
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/555,105 Expired - Lifetime US7805401B2 (en) | 2003-04-14 | 2006-10-31 | Method and apparatus for splitting a replicated volume |
Country Status (1)
Country | Link |
---|---|
US (1) | US7805401B2 (en) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080281788A1 (en) * | 2007-05-09 | 2008-11-13 | Ophir Frieder | Hierarchical structured abstract file system |
US20180225288A1 (en) * | 2017-02-07 | 2018-08-09 | Oracle International Corporation | Systems and methods for live data migration with automatic redirection |
US20190220538A1 (en) * | 2018-01-12 | 2019-07-18 | International Business Machines Corporation | Cloning of a system |
US10997208B2 (en) * | 2019-02-13 | 2021-05-04 | Sap Se | In-memory database-managed container volume replication |
US11238063B2 (en) * | 2019-07-25 | 2022-02-01 | EMC IP Holding Company LLC | Provenance-based replication in a storage system |
US11385903B2 (en) * | 2020-02-04 | 2022-07-12 | Microsoft Technology Licensing, Llc | Firmware update patch |
US11403320B2 (en) | 2019-03-06 | 2022-08-02 | Sap Se | Elastic in-memory database provisioning on database-as-a-service |
US11422973B2 (en) | 2019-03-06 | 2022-08-23 | Sap Se | Peer-to-peer delta image dispatch system |
US11481206B2 (en) | 2019-05-16 | 2022-10-25 | Microsoft Technology Licensing, Llc | Code update in system management mode |
US11954122B2 (en) * | 2023-01-23 | 2024-04-09 | Sap Se | In-memory database-managed container volume replication |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008276488A (en) * | 2007-04-27 | 2008-11-13 | Hitachi Ltd | Storage system and information migration method for storage system |
WO2009123614A1 (en) * | 2008-03-31 | 2009-10-08 | Hewlett-Packard Development Company, L.P. | Updating retrieval codes in response to file transfers |
US9058334B2 (en) * | 2010-02-11 | 2015-06-16 | Emc Corporation | Parallel file system processing |
US9104966B2 (en) * | 2011-11-23 | 2015-08-11 | Tata Consultancy Services Limited | Self configuring knowledge base representation |
CN103942205B (en) * | 2013-01-18 | 2018-06-05 | 深圳市腾讯计算机系统有限公司 | Storage, the method, apparatus and system for reading directory index |
US9939272B1 (en) * | 2017-01-06 | 2018-04-10 | TCL Research America Inc. | Method and system for building personalized knowledge base of semantic image segmentation via a selective random field approach |
Citations (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4467421A (en) * | 1979-10-18 | 1984-08-21 | Storage Technology Corporation | Virtual storage system and method |
US4601012A (en) * | 1983-03-11 | 1986-07-15 | International Business Machines Corporation | Zone partitioning in volume recovery system |
US4853843A (en) * | 1987-12-18 | 1989-08-01 | Tektronix, Inc. | System for merging virtual partitions of a distributed database |
US5060185A (en) * | 1988-03-25 | 1991-10-22 | Ncr Corporation | File backup system |
US5276867A (en) * | 1989-12-19 | 1994-01-04 | Epoch Systems, Inc. | Digital data storage system with improved data migration |
US5367698A (en) * | 1991-10-31 | 1994-11-22 | Epoch Systems, Inc. | Network file migration system |
US5423018A (en) * | 1992-11-16 | 1995-06-06 | International Business Machines Corporation | Queue time reduction in a data storage hierarchy using volume mount rate |
US5537585A (en) * | 1994-02-25 | 1996-07-16 | Avail Systems Corporation | Data storage management for network interconnected processors |
US5555371A (en) * | 1992-12-17 | 1996-09-10 | International Business Machines Corporation | Data backup copying with delayed directory updating and reduced numbers of DASD accesses at a back up site using a log structured array data storage |
US5671350A (en) * | 1993-09-30 | 1997-09-23 | Sybase, Inc. | Data backup system with methods for stripe affinity backup to multiple archive devices |
US5812748A (en) * | 1993-06-23 | 1998-09-22 | Vinca Corporation | Method for improving recovery performance from hardware and software errors in a fault-tolerant computer system |
US5832487A (en) * | 1994-12-15 | 1998-11-03 | Novell, Inc. | Replicated object identification in a partitioned hierarchy |
US5832274A (en) * | 1996-10-09 | 1998-11-03 | Novell, Inc. | Method and system for migrating files from a first environment to a second environment |
US5875479A (en) * | 1997-01-07 | 1999-02-23 | International Business Machines Corporation | Method and means for making a dual volume level copy in a DASD storage subsystem subject to updating during the copy interval |
US5956718A (en) * | 1994-12-15 | 1999-09-21 | Novell, Inc. | Method and apparatus for moving subtrees in a distributed network directory |
US5960194A (en) * | 1995-09-11 | 1999-09-28 | International Business Machines Corporation | Method for generating a multi-tiered index for partitioned data |
US5991771A (en) * | 1995-07-20 | 1999-11-23 | Novell, Inc. | Transaction synchronization in a disconnectable computer and network |
US6061770A (en) * | 1997-11-04 | 2000-05-09 | Adaptec, Inc. | System and method for real-time data backup using snapshot copying with selective compaction of backup data |
US6101585A (en) * | 1997-11-04 | 2000-08-08 | Adaptec, Inc. | Mechanism for incremental backup of on-line files |
US6105062A (en) * | 1998-02-26 | 2000-08-15 | Novell, Inc. | Method and system for pruning and grafting trees in a directory service |
US20020049718A1 (en) * | 1993-06-03 | 2002-04-25 | Kleiman Steven R. | File system image transfer |
US6408298B1 (en) * | 1999-12-15 | 2002-06-18 | Microsoft Corporation | Methods and systems for copying and moving across virtual namespaces |
US6457011B1 (en) * | 1999-07-23 | 2002-09-24 | Microsoft Corporation | Method of updating a shared database in a computer network |
US20030028737A1 (en) * | 1999-09-30 | 2003-02-06 | Fujitsu Limited | Copying method between logical disks, disk-storage system and its storage medium |
US6647393B1 (en) * | 1996-11-22 | 2003-11-11 | Mangosoft Corporation | Dynamic directory service |
US6678700B1 (en) * | 2000-04-27 | 2004-01-13 | General Atomics | System of and method for transparent management of data objects in containers across distributed heterogenous resources |
US20040205088A1 (en) * | 2003-04-14 | 2004-10-14 | Novell, Inc. | Method and apparatus for moving data between storage devices |
US6898609B2 (en) * | 2002-05-10 | 2005-05-24 | Douglas W. Kerwin | Database scattering system |
US6925541B2 (en) * | 2002-06-12 | 2005-08-02 | Hitachi, Ltd. | Method and apparatus for managing replication volumes |
US6931410B2 (en) * | 2002-01-11 | 2005-08-16 | International Business Machines Corporation | Method, apparatus, and program for separate representations of file system locations from referring file systems |
US6934723B2 (en) * | 1999-12-23 | 2005-08-23 | International Business Machines Corporation | Method for file system replication with broadcasting and XDSM |
US6944621B1 (en) * | 1999-04-21 | 2005-09-13 | Interactual Technologies, Inc. | System, method and article of manufacture for updating content stored on a portable storage medium |
US6957221B1 (en) * | 2002-09-05 | 2005-10-18 | Unisys Corporation | Method for capturing a physically consistent mirrored snapshot of an online database from a remote database backup system |
US7032003B1 (en) * | 2001-08-13 | 2006-04-18 | Union Gold Holdings, Ltd. | Hybrid replication scheme with data and actions for wireless devices |
US7054910B1 (en) * | 2001-12-20 | 2006-05-30 | Emc Corporation | Data replication facility for distributed computing environments |
US20060136443A1 (en) * | 2004-12-16 | 2006-06-22 | International Business Machines Corporation | Method and apparatus for initializing data propagation execution for large database replication |
US7080102B2 (en) * | 2002-03-25 | 2006-07-18 | Emc Corporation | Method and system for migrating data while maintaining hard links |
US7191298B2 (en) * | 2002-08-02 | 2007-03-13 | International Business Machines Corporation | Flexible system and method for mirroring data |
US20070192551A1 (en) * | 2006-02-14 | 2007-08-16 | Junichi Hara | Method for mirroring data between clustered NAS systems |
US7290017B1 (en) * | 2001-09-20 | 2007-10-30 | Emc Corporation | System and method for management of data replication |
US7310644B2 (en) * | 2001-06-06 | 2007-12-18 | Microsoft Corporation | Locating potentially identical objects across multiple computers |
US7349913B2 (en) * | 2003-08-21 | 2008-03-25 | Microsoft Corporation | Storage platform for organizing, searching, and sharing data |
US7370025B1 (en) * | 2002-12-17 | 2008-05-06 | Symantec Operating Corporation | System and method for providing access to replicated data |
US7389393B1 (en) * | 2004-10-21 | 2008-06-17 | Symantec Operating Corporation | System and method for write forwarding in a storage environment employing distributed virtualization |
US7475199B1 (en) * | 2000-10-19 | 2009-01-06 | Emc Corporation | Scalable network file system |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5675725A (en) | 1993-07-19 | 1997-10-07 | Cheyenne Advanced Technology Limited | Computer backup system operable with open files |
-
2006
- 2006-10-31 US US11/555,105 patent/US7805401B2/en not_active Expired - Lifetime
Patent Citations (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4467421A (en) * | 1979-10-18 | 1984-08-21 | Storage Technology Corporation | Virtual storage system and method |
US4601012A (en) * | 1983-03-11 | 1986-07-15 | International Business Machines Corporation | Zone partitioning in volume recovery system |
US4853843A (en) * | 1987-12-18 | 1989-08-01 | Tektronix, Inc. | System for merging virtual partitions of a distributed database |
US5060185A (en) * | 1988-03-25 | 1991-10-22 | Ncr Corporation | File backup system |
US5276867A (en) * | 1989-12-19 | 1994-01-04 | Epoch Systems, Inc. | Digital data storage system with improved data migration |
US5367698A (en) * | 1991-10-31 | 1994-11-22 | Epoch Systems, Inc. | Network file migration system |
US5423018A (en) * | 1992-11-16 | 1995-06-06 | International Business Machines Corporation | Queue time reduction in a data storage hierarchy using volume mount rate |
US5555371A (en) * | 1992-12-17 | 1996-09-10 | International Business Machines Corporation | Data backup copying with delayed directory updating and reduced numbers of DASD accesses at a back up site using a log structured array data storage |
US20020049718A1 (en) * | 1993-06-03 | 2002-04-25 | Kleiman Steven R. | File system image transfer |
US5812748A (en) * | 1993-06-23 | 1998-09-22 | Vinca Corporation | Method for improving recovery performance from hardware and software errors in a fault-tolerant computer system |
US5671350A (en) * | 1993-09-30 | 1997-09-23 | Sybase, Inc. | Data backup system with methods for stripe affinity backup to multiple archive devices |
US5537585A (en) * | 1994-02-25 | 1996-07-16 | Avail Systems Corporation | Data storage management for network interconnected processors |
US5832487A (en) * | 1994-12-15 | 1998-11-03 | Novell, Inc. | Replicated object identification in a partitioned hierarchy |
US5956718A (en) * | 1994-12-15 | 1999-09-21 | Novell, Inc. | Method and apparatus for moving subtrees in a distributed network directory |
US5991771A (en) * | 1995-07-20 | 1999-11-23 | Novell, Inc. | Transaction synchronization in a disconnectable computer and network |
US5960194A (en) * | 1995-09-11 | 1999-09-28 | International Business Machines Corporation | Method for generating a multi-tiered index for partitioned data |
US5832274A (en) * | 1996-10-09 | 1998-11-03 | Novell, Inc. | Method and system for migrating files from a first environment to a second environment |
US6647393B1 (en) * | 1996-11-22 | 2003-11-11 | Mangosoft Corporation | Dynamic directory service |
US5875479A (en) * | 1997-01-07 | 1999-02-23 | International Business Machines Corporation | Method and means for making a dual volume level copy in a DASD storage subsystem subject to updating during the copy interval |
US6101585A (en) * | 1997-11-04 | 2000-08-08 | Adaptec, Inc. | Mechanism for incremental backup of on-line files |
US6061770A (en) * | 1997-11-04 | 2000-05-09 | Adaptec, Inc. | System and method for real-time data backup using snapshot copying with selective compaction of backup data |
US6105062A (en) * | 1998-02-26 | 2000-08-15 | Novell, Inc. | Method and system for pruning and grafting trees in a directory service |
US6944621B1 (en) * | 1999-04-21 | 2005-09-13 | Interactual Technologies, Inc. | System, method and article of manufacture for updating content stored on a portable storage medium |
US6457011B1 (en) * | 1999-07-23 | 2002-09-24 | Microsoft Corporation | Method of updating a shared database in a computer network |
US20030028737A1 (en) * | 1999-09-30 | 2003-02-06 | Fujitsu Limited | Copying method between logical disks, disk-storage system and its storage medium |
US6408298B1 (en) * | 1999-12-15 | 2002-06-18 | Microsoft Corporation | Methods and systems for copying and moving across virtual namespaces |
US6934723B2 (en) * | 1999-12-23 | 2005-08-23 | International Business Machines Corporation | Method for file system replication with broadcasting and XDSM |
US6678700B1 (en) * | 2000-04-27 | 2004-01-13 | General Atomics | System of and method for transparent management of data objects in containers across distributed heterogenous resources |
US7475199B1 (en) * | 2000-10-19 | 2009-01-06 | Emc Corporation | Scalable network file system |
US7310644B2 (en) * | 2001-06-06 | 2007-12-18 | Microsoft Corporation | Locating potentially identical objects across multiple computers |
US7032003B1 (en) * | 2001-08-13 | 2006-04-18 | Union Gold Holdings, Ltd. | Hybrid replication scheme with data and actions for wireless devices |
US7290017B1 (en) * | 2001-09-20 | 2007-10-30 | Emc Corporation | System and method for management of data replication |
US7054910B1 (en) * | 2001-12-20 | 2006-05-30 | Emc Corporation | Data replication facility for distributed computing environments |
US6931410B2 (en) * | 2002-01-11 | 2005-08-16 | International Business Machines Corporation | Method, apparatus, and program for separate representations of file system locations from referring file systems |
US7080102B2 (en) * | 2002-03-25 | 2006-07-18 | Emc Corporation | Method and system for migrating data while maintaining hard links |
US6898609B2 (en) * | 2002-05-10 | 2005-05-24 | Douglas W. Kerwin | Database scattering system |
US6925541B2 (en) * | 2002-06-12 | 2005-08-02 | Hitachi, Ltd. | Method and apparatus for managing replication volumes |
US7191298B2 (en) * | 2002-08-02 | 2007-03-13 | International Business Machines Corporation | Flexible system and method for mirroring data |
US6957221B1 (en) * | 2002-09-05 | 2005-10-18 | Unisys Corporation | Method for capturing a physically consistent mirrored snapshot of an online database from a remote database backup system |
US7370025B1 (en) * | 2002-12-17 | 2008-05-06 | Symantec Operating Corporation | System and method for providing access to replicated data |
US20040205088A1 (en) * | 2003-04-14 | 2004-10-14 | Novell, Inc. | Method and apparatus for moving data between storage devices |
US7349913B2 (en) * | 2003-08-21 | 2008-03-25 | Microsoft Corporation | Storage platform for organizing, searching, and sharing data |
US7389393B1 (en) * | 2004-10-21 | 2008-06-17 | Symantec Operating Corporation | System and method for write forwarding in a storage environment employing distributed virtualization |
US20060136443A1 (en) * | 2004-12-16 | 2006-06-22 | International Business Machines Corporation | Method and apparatus for initializing data propagation execution for large database replication |
US20070192551A1 (en) * | 2006-02-14 | 2007-08-16 | Junichi Hara | Method for mirroring data between clustered NAS systems |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7720869B2 (en) * | 2007-05-09 | 2010-05-18 | Illinois Institute Of Technology | Hierarchical structured abstract file system |
US20080281788A1 (en) * | 2007-05-09 | 2008-11-13 | Ophir Frieder | Hierarchical structured abstract file system |
US10997132B2 (en) * | 2017-02-07 | 2021-05-04 | Oracle International Corporation | Systems and methods for live data migration with automatic redirection |
US20180225288A1 (en) * | 2017-02-07 | 2018-08-09 | Oracle International Corporation | Systems and methods for live data migration with automatic redirection |
US20190220538A1 (en) * | 2018-01-12 | 2019-07-18 | International Business Machines Corporation | Cloning of a system |
US10754876B2 (en) * | 2018-01-12 | 2020-08-25 | International Business Machines Corporation | Cloning of a system |
US11625418B2 (en) * | 2019-02-13 | 2023-04-11 | Sap Se | In-memory database-managed container volume replication |
US10997208B2 (en) * | 2019-02-13 | 2021-05-04 | Sap Se | In-memory database-managed container volume replication |
US11403320B2 (en) | 2019-03-06 | 2022-08-02 | Sap Se | Elastic in-memory database provisioning on database-as-a-service |
US11422973B2 (en) | 2019-03-06 | 2022-08-23 | Sap Se | Peer-to-peer delta image dispatch system |
US11803514B2 (en) | 2019-03-06 | 2023-10-31 | Sap Se | Peer-to-peer delta image dispatch system |
US11899687B2 (en) | 2019-03-06 | 2024-02-13 | Sap Se | Elastic in-memory database provisioning on database-as-a-service |
US11481206B2 (en) | 2019-05-16 | 2022-10-25 | Microsoft Technology Licensing, Llc | Code update in system management mode |
US11238063B2 (en) * | 2019-07-25 | 2022-02-01 | EMC IP Holding Company LLC | Provenance-based replication in a storage system |
US11385903B2 (en) * | 2020-02-04 | 2022-07-12 | Microsoft Technology Licensing, Llc | Firmware update patch |
US11954122B2 (en) * | 2023-01-23 | 2024-04-09 | Sap Se | In-memory database-managed container volume replication |
Also Published As
Publication number | Publication date |
---|---|
US20090119344A9 (en) | 2009-05-07 |
US7805401B2 (en) | 2010-09-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7805401B2 (en) | Method and apparatus for splitting a replicated volume | |
US8046555B2 (en) | Method of mirroring data between clustered NAS systems | |
US10209893B2 (en) | Massively scalable object storage for storing object replicas | |
US8572136B2 (en) | Method and system for synchronizing a virtual file system at a computing device with a storage device | |
US8700573B2 (en) | File storage service system, file management device, file management method, ID denotative NAS server and file reading method | |
US6311213B2 (en) | System and method for server-to-server data storage in a network environment | |
US8176008B2 (en) | Apparatus and method for replicating data in file system | |
US6922761B2 (en) | Method and system for migrating data | |
US8510267B2 (en) | Synchronization of structured information repositories | |
US8712975B2 (en) | Modification of an object replica | |
EP1325409B1 (en) | A shared file system having a token-ring style protocol for managing meta-data | |
US20030236850A1 (en) | Storage system for content distribution | |
US9122397B2 (en) | Exposing storage resources with differing capabilities | |
EP1902394B1 (en) | Moving data from file on storage volume to alternate location to free space | |
US20060129616A1 (en) | System and method for synchronizing computer files between a local computer and a remote server | |
US20070143286A1 (en) | File management method in file system and metadata server therefor | |
EP1480130B1 (en) | Method and apparatus for moving data between storage devices | |
US7080102B2 (en) | Method and system for migrating data while maintaining hard links | |
US8332351B2 (en) | Method and system for preserving files with multiple links during shadow migration | |
US8667034B1 (en) | System and method for preserving symbolic links by a storage virtualization system | |
US6952699B2 (en) | Method and system for migrating data while maintaining access to data with use of the same pathname |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: NOVELL, INC., UTAH Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:TONER, STEPHEN G.;REEL/FRAME:018462/0931 Effective date: 20061030 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: ORACLE INTERNATIONAL CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CPTN HOLDINGS LLC;REEL/FRAME:027147/0396 Effective date: 20110909 Owner name: CPTN HOLDINGS LLC, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NOVELL, INC.;REEL/FRAME:027147/0151 Effective date: 20110427 |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552) Year of fee payment: 8 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 12 |