Source: http://www.google.com/patents/US20050015409?dq=2040248
Timestamp: 2016-06-25 08:22:25
Document Index: 647755239

Matched Legal Cases: ['art 300', 'art 300', 'art 400', 'art 400', 'art 500', 'art 500']

Patent US20050015409 - Techniques for performing operations on migrated files without recalling data - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsTechniques for performing operations on migrated files without triggering a recall of the migrated data. For example, embodiments of the present invention can perform a copy, move, or delete operation on a migrated file without recalling the migrated data associated with the file....http://www.google.com/patents/US20050015409?utm_source=gb-gplus-sharePatent US20050015409 - Techniques for performing operations on migrated files without recalling dataAdvanced Patent SearchPublication numberUS20050015409 A1Publication typeApplicationApplication numberUS 10/857,176Publication dateJan 20, 2005Filing dateMay 28, 2004Priority dateMay 30, 2003Also published asWO2004109556A1Publication number10857176, 857176, US 2005/0015409 A1, US 2005/015409 A1, US 20050015409 A1, US 20050015409A1, US 2005015409 A1, US 2005015409A1, US-A1-20050015409, US-A1-2005015409, US2005/0015409A1, US2005/015409A1, US20050015409 A1, US20050015409A1, US2005015409 A1, US2005015409A1InventorsWen Cheng, Rini Kaushik, Bob GrewalOriginal AssigneeArkivio, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (54), Referenced by (44), Classifications (6), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetTechniques for performing operations on migrated files without recalling data
BRIEF DESCRIPTION OF THE DRAWINGS [0017] FIG. 1 is a simplified block diagram of a storage environment that may incorporate an embodiment of the present invention; [0018] FIG. 2 is a simplified block diagram of a data processing system that maybe used to perform processing according to an embodiment of the present invention; [0019] FIG. 3 is a simplified high-level flowchart depicting a method of copying a file without performing a recall according to an embodiment of the present invention; [0020] FIG. 4 is a simplified high-level flowchart depicting a method of moving a file without performing a recall according to an embodiment of the present invention; and [0021] FIG. 5 is a simplified high-level flowchart depicting a method of deleting a file without performing a recall according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION [0022] In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of the invention. However, it will be apparent that the invention may be practiced without these specific details. [0023] FIG. 1 is a simplified block diagram of a storage environment 100 that may incorporate an embodiment of the present invention. Storage environment 100 depicted in FIG. 1 is merely illustrative of an embodiment incorporating the present invention and does not limit the scope of the invention as recited in the claims. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. [0024] As depicted in FIG. 1, storage environment 100 comprises a plurality of physical storage devices or units 102 for storing data. Physical storage units 102 may include disk drives, tapes, hard drives, optical disks, RAID storage structures, solid state storage devices, SAN storage devices, NAS storage devices, and other types of devices and storage media capable of storing data. The term “physical storage unit” is intended to refer to any physical device, system, etc. that is capable of storing information or data. [0025] Physical storage units 102 may be organized into one or more logical storage units 104 that provide a logical view of underlying disks provided by physical storage units 102. Each logical storage unit (e.g., a volume) is generally identifiable by a unique identifier (e.g., a number, name, etc.) that may be specified by the user. A single physical storage unit may be divided into several separately identifiable logical storage units. A single logical storage unit may span storage space provided by multiple physical storage units 102. A logical storage unit may reside on non-contiguous physical partitions. By using logical storage units, the physical storage units and the distribution of data across the physical storage units becomes transparent to servers and applications. [0026] For purposes of description, logical storage units 104 are considered to be in the form of volumes. However, other types of logical storage units are also within the scope of the present invention. The term “storage unit” is intended to refer to a physical storage unit (e.g., a disk) or a logical storage unit (e.g., a volume). [0027] Storage environment 100 also comprises several servers 106. Servers 106 may be data processing systems that are configured to provide a service. One or more volumes from logical storage units 104 may be assigned or allocated to servers 106. For example, as depicted in FIG. 1, volumes V1 and V2 are assigned to server (S1) 106-1, volume V3 is assigned to server (S2) 106-2, and volumes V4 and V5 are assigned to server (S3) 106-3. A server 106 provides an access point for the one or more volumes allocated to that server. [0028] According to an embodiment of the present invention, a storage management server/system (SMS) 110 may be coupled to the storage resources and to servers 106 via communication network 108 (as shown in FIG. 1) or directly. Communication network 108 provides a mechanism for allowing communication between SMS 110 and servers 106. Communication network 108 may be a local area network (LAN), a wide area network (WAN), a wireless network, an Intranet, the Internet, a private network, a public network, a switched network, or any other suitable communication network. Communication network 108 may comprise many interconnected computer systems and communication links. The communication links may be hardwire links, optical links, satellite or other wireless communications links, wave propagation links, or any other mechanisms for communication of information. Various communication protocols may be used to facilitate communication of information via the communication links, including TCP/IP, HTTP protocols, extensible markup language (XML), wireless application protocol (WAP), Fiber Channel protocols, protocols under development by industry standard organizations, vendor-specific protocols, customized protocols, and others. [0029] SMS 110 may be configured to execute applications that provide storage management services for storage environment 100. For example, storage management applications (e.g., HSM applications, ILM applications, etc.) that control migration and recall of data may be executed by SMS 110. The storage applications may also be executed by other servers. According to an embodiment of the present invention, SMS 110 is configured to execute an application or process that enables operations (e.g., copy, move, and delete) to be performed on files stored by the storage environment without performing a recall operation. The processing according to the teachings of the present invention may also be performed by servers 106, or by servers 106 in conjunction with SMS 110. [0030] As depicted in FIG. 1, SMS 110 may have access to information that facilitates the performance of file operations without recalling data. As shown in FIG. 1, the information may be stored in database 112. The information stored in database 112 may include file location information 114 that comprises information related to files that have been migrated, recalled, etc. File location information 114 may be used to locate migrated data for files that have been migrated. File location information 114 or portions thereof may also be stored on or replicated in databases on servers 106. Database 112 may also store other information 116 that may include information related to storage policies and rules configured for the storage environment, information related to the various monitored storage units, information related to the files stored in the storage environment, and the like. Database 112 may be embodied in various forms including a relational database, directory services, data structure, etc. The information may be stored in various formats. [0031] FIG. 2 is a simplified block diagram of SMS 110 (or any data processing system) that may be used to perform processing according to an embodiment of the present invention. As shown in FIG. 2, SMS 110 includes a processor 202 that communicates with a number of peripheral devices via a bus subsystem 204. These peripheral devices may include a storage subsystem 206, comprising a memory subsystem 208 and a file storage subsystem 210, user interface input devices 212, user interface output devices 214, and a network interface subsystem 216. The input and output devices allow a user, such as the administrator, to interact with SMS 110. [0032] Network interface subsystem 216 provides an interface to other computer systems, networks, servers, and storage units. Network interface subsystem 216 serves as an interface for receiving data from other sources and for transmitting data to other sources from SMS 110. Embodiments of network interface subsystem 216 include an Ethernet card, a modem (telephone, satellite, cable, ISDN, etc.), (asynchronous) digital subscriber line (DSL) units, and the like. [0033] User interface input devices 212 may include a keyboard, pointing devices such as a mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touchscreen incorporated into the display, audio input devices such as voice recognition systems, microphones, and other types of input devices. In general, use of the term “input device” is intended to include all possible types of devices and mechanisms for inputting information to SMS 110. [0034] User interface output devices 214 may include a display subsystem, a printer, a fax machine, or non-visual displays such as audio output devices, etc. The display subsystem may be a cathode ray tube (CRT), a flat-panel device such as a liquid crystal display (LCD), or a projection device. In general, use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from SMS 110. [0035] Storage subsystem 206 may be configured to store the basic programming and data constructs that provide the functionality of the present invention. For example, according to an embodiment of the present invention, software code modules (or instructions) implementing the functionality of the present invention may be stored in storage subsystem 206. These software modules or instructions may be executed by processor(s) 202. Storage subsystem 206 may also provide a repository for storing data used in accordance with the present invention. For example, information used for enabling operations to be performed on files without performing recalls may be stored in storage subsystem 206. Storage subsystem 206 may also be used as a migration repository to store data that is moved from a storage unit. Storage subsystem 206 may also be used to store data that is moved from another storage unit. Storage subsystem 206 may comprise memory subsystem 208 and file/disk storage subsystem 210. [0036] Memory subsystem 208 may include a number of memories including a main random access memory (RAM) 218 for storage of instructions and data during program execution and a read only memory (ROM) 220 in which fixed instructions are stored. File storage subsystem 210 provides persistent (non-volatile) storage for program and data files, and may include a hard disk drive, a floppy disk drive along with associated removable media, a Compact Disk Read Only Memory (CD-ROM) drive, an optical drive, removable media cartridges, and other like storage media. [0037] Bus subsystem 204 provides a mechanism for letting the various components and subsystems of SMS 110 communicate with each other as intended. Although bus subsystem 204 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple busses. [0038] SMS 110 can be of various types including a personal computer, a portable computer, a workstation, a network computer, a mainframe, a kiosk, or any other data processing system. Due to the ever-changing nature of computers and networks, the description of SMS 110 depicted in FIG. 2 is intended only as a specific example for purposes of illustrating the preferred embodiment of the computer system. Many other configurations having more or fewer components than the system depicted in FIG. 2 are possible. [0039] Servers 106 and SMS 100 facilitate migration, remigration, and recall operations for files stored by storage units of storage environment 100. According to an embodiment of the present invention, servers 106 and SMS 100 enable file operations to be performed on the migrated files without triggering a recall. The following notations will be used in this application to facilitate discussion of the present invention. These notations are not intended to limit the scope of the present invention as recited in the claims. [0040] An “original storage location” is a storage location (e.g., a directory) where a file is stored before the file is migrated. [0041] An “original storage unit” is a storage unit that comprises the original storage location. An “original volume” is a volume comprising the original storage location. [0042] An “original server” is a server to which the original storage unit or original volume is allocated. The original server may be configured to manage access to the original storage unit or volume. [0043] A “repository storage location” is a storage location (e.g., a directory) where the migrated or remigrated data from a migrated file is stored. [0044] A “repository storage unit” is a storage unit on which the repository storage location is located. A “repository volume” is a volume on which the repository storage location is located. [0045] A “repository server” is a server to which the repository storage unit or repository volume is allocated. The repository server may be configured to manage access to the repository storage unit or volume. [0046] A “target storage location” is a storage location to which a file is to be moved or copied. [0047] A “target storage unit” is a storage unit that comprises the target storage location. A “target volume” is a volume comprising the target storage location. [0048] Migration is a process or operation where a portion (or even the entire file) of the file being migrated is moved from an original storage location on an original volume where the file is stored to a repository storage location on a repository volume. The migrated portion of the file may include, for example, the data portion of the file. In certain embodiments, the migrated portion of the file may also include a portion of (or the entire) metadata associated with the file. The metadata may comprise attributes such as security attributes (e.g., ownership information, permissions information, access control lists, etc.), file attributes (e.g., file size, file creation information, file modification information, access time information, etc.), extended attributes (attributes specific to certain file systems, e.g., subject information, title information), sparse attributes, alternate streams, etc. associated with the file. [0049] As a result of migration, a stub or tag file may be left in place of the original file in the original storage location on the original volume. The stub file is a physical file that serves as an entity in the original storage location that is visible to the user and/or applications and through which the user and/or applications can access the original file. Users and applications can access the migrated file as though the file was still stored in the original storage location using the stub file. When a storage management application (e.g., HSM, ILM) receives a request to access the migrated file, the application determines the repository storage location of the migrated data corresponding to the stub file and recalls (or demigrates) the migrated file data from the repository storage location back to the original storage location. The location of the migrated data may be determined from a database storing information for migrated files. For example, the information may be stored in a database such as database 112 depicted in FIG. 1 as part of file location information 114. In some embodiments, the location may also be determined from information stored in the stub file. [0050] The information stored in a stub file may vary in different storage environments. For example, in one embodiment, a stub file may store information that may be used by the storage management application to locate the migrated data. In some embodiments, a stub file may store attributes or metadata associated with the migrated file. The metadata may include information related to various attributes associated with the migrated file such as security attributes, file attributes, extended attributes, etc. In certain embodiments, the stub file may also store or cache a portion of the data portion of the file. [0051] In some embodiments, as a result of migration, information related to the migrated files such as information identifying the original volume, the repository volume, information identifying the repository storage location, etc. may also be stored in a centralized location. For example, the information may be stored in a database such as database 112 depicted in FIG. 1 as part of file location information 114. [0052] A recall operation is an operation in which the migrated portion of a file is recalled or moved from the repository storage location (on the repository storage unit) back to the original storage location on the original storage unit. A recall is usually performed when a request is received to access a migrated file. According to one embodiment, as part of the recall operation, the original server identifies the repository server from information stored in the stub file (or from information stored in a database such as file location information 114 depicted in FIG. 1) corresponding to file to be recalled. The migrated data is then recalled from the repository storage location on the repository volume to the original storage location on the original volume. [0053] According to the teachings of the present invention, file operations, which would conventionally trigger a recall, are performed for migrated files without triggering a recall operation for the file. Examples of such operations include copying a migrated file, moving a migrated file, deleting a migrated file, etc. In general, the teachings of the present invention may be applied to any file operation that would trigger a recall. [0054] FIG. 3 is a simplified high-level flowchart 300 depicting a method of copying a file without performing a recall according to an embodiment of the present invention. The method depicted in FIG. 3 may be performed by software modules executed by a processor, hardware modules, or combinations thereof. Flowchart 300 depicted in FIG. 3 is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are also within the scope of the present invention. The method depicted in FIG. 3 may be adapted to work with different implementation constraints. [0055] As depicted in FIG. 3, processing is initiated upon receiving a request to copy a file to a target storage location (e.g., a target directory) (step 302). The target storage location may be on the same storage unit (e.g., same volume) as where the file is originally stored or on a different storage unit. The request may be received responsive to a user action (e.g., the user requests the file to be copied) or may be received from an application or process (e.g., an application that is configured to perform file operations, etc.), etc. [0056] A determination is then made if the specified file to be copied has been migrated (step 304). The determination may be made using several techniques. According to one technique, if a stub file is located in place of the actual file in the original storage location, then this indicates that the file has been migrated. According to another technique, information stored for migrated files (e.g., file location information 114 stored in database 112) may be queried to determine if the specified file to be copied has been migrated. [0057] If it is determined in 304 that the file has not been migrated, then the file is copied to the specified target storage location (step 306) and this completes the file copy operation. Since the file has not been migrated, no recall operation needs to be performed. [0058] If it is determined in step 304 that the file has been migrated, then the location of the migrated portion of the file to be copied is determined (step 308). As part of 308, the repository storage location and the repository storage unit (e.g., the repository volume) may be determined. In one embodiment, the location of the migrated portion of the file may be determined from information stored in a stub file located in the original storage location in place of the file to be copied. The location of the migrated file data may also be determined from file location information 114 stored in database 112. In certain embodiments, information in the stub file and the file location information may be used in conjunction to determine the location of the migrated file data. [0059] A target file is then created in the target storage location by copying the migrated portion of the specified file from the repository storage location determined in step 308 to the specified target storage location (step 310). The migrated portion of the file may comprise the data portion of the file. In some embodiments, the migrated data may also include metadata associated with the file, and the metadata is also copied to the target file in 310. [0060] Metadata stored in the stub file corresponding to the file to be copied may then be copied to the target file created in 310 (step 312). The metadata associated with the stub file may include attributes such as security attributes (e.g., ownership information, permissions information, access control lists, etc.), file attributes (e.g., file size, file creation information, file modification information, access time information, etc.), extended attributes (attributes specific to certain operating systems, e.g., subject information, title information), sparse attributes, alternate streams, etc. associated with the file. After 312, the target file is the recreation of the specified file prior to the migration and thus is a copy of the specified file. Step 312 may not be performed if the metadata associated with the file has already been copied to the target file in 310. [0061] According to an embodiment of the present invention, in 312, for security attributes associated with the stub file, only the non-inherited security attributes are applied to the target file. For example, a file may inherit security attributes (e.g., read, write, view attributes) from the directory in which the file is located or from the directory structure in which the file is located. Such inherited security attributes are not copied or applied to the target file as they are not attributes that are native to the file. [0062] The file copy operation is completed after completion of step 312. As described above, the copying of the migrated file is achieved without triggering a recall. In this manner, the problems associated with recalls such as increased network traffic that can degrade the performance of the storage environment are avoided. Further, copy operations may be successfully performed even if the original storage unit does not have sufficient storage capacity to store the recalled file data. [0063] Various measures may be used to preserve the consistency of the file system due to errors that may occur during the copy operation described above. For example, at the start of the copy operation, the status of the file may be marked as “copy in progress”. The original file may be saved in memory for rollback purposes in case or errors that may occur. If an error occurs during the copy operation, then the file status for the original file may be rolled back to its original status and the stub file and the migrated data in the repository storage location are left unchanged. [0064] FIG. 4 is a simplified high-level flowchart 400 depicting a method of moving a file without performing a recall according to an embodiment of the present invention. The method depicted in FIG. 4 may be performed by software modules executed by a processor, hardware modules, or combinations thereof. Flowchart 400 depicted in FIG. 4 is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are also within the scope of the present invention. The method depicted in FIG. 4 may be adapted to work with different implementation constraints. [0065] As depicted in FIG. 4, processing is initiated upon receiving a request to move a file from its current location to a target storage location (e.g., a target directory) (step 402). The target storage location may be on the same storage unit (e.g., same volume) as where the file is presently stored or on a different storage unit. The request may be received responsive to a user action (e.g., the user requests the file to be moved), or may be received from an application or process (e.g., an application that is configured to perform backup operations, etc.), etc. [0066] A determination is then made if the specified file to be moved has been migrated (step 404). As previously described, such a determination may be made using several techniques. For example, if a stub file is located in place of the file, then this indicates that the file has been migrated. Alternatively, information stored for the migrated files (e.g., file location information 114 stored in database 112) may be queried to determine if the specified file to be moved has been migrated. [0067] If it is determined in 404 that the specified file has not been migrated, then the file is moved to the specified target storage location (step 406) and this completes the file move operation. Since the file has not been migrated, no recall operation needs to be performed as a result of the move operation. [0068] If it is determined in step 404 that the specified file has been migrated, then the location of the migrated portion of the file to be moved is determined (step 408). As part of 408, the repository storage location and the repository storage unit (e.g., the repository volume) may be determined. As previously described, the location of the migrated portion of the file to be moved may be determined from information stored in a stub file located in the original storage location in place of the specified file to be moved. The location of the migrated file portion may also be determined from file location information 114 stored in database 112. In some embodiments, information in the stub file and the file location information may be used in conjunction to determine the location of the migrated file data. [0069] A target file is then created in the target storage location by copying the migrated file portion of the specified file from the repository storage location determined in step 408 to the specified target storage location (step 410). The migrated portion of the file may comprise the data portion of the file. In some embodiments, the migrated data may also include metadata associated with the file, and the metadata is also copied to the target file in 410. [0070] Metadata stored in the stub file corresponding to the specified file may then be copied to the target file created in 410 (step 412). As previously stated, the metadata associated with the stub file may include attributes such as security attributes (e.g., ownership information, permissions information, access control lists, etc.), file attributes (e.g., file size, file creation information, file modification information, access time information, etc.), extended attributes (attributes specific to certain operating systems, e.g., subject information, title information), sparse attributes, alternate streams, etc. associated with the file. After 412, the target file is the recreation of the specified file prior to the migration and thus is a copy of the specified file. Step 412 may not be performed if the metadata associated with the file has already been copied to the target file in 410. [0071] According to an embodiment of the present invention, in 412, for security attributes associated with the stub file, only the non-inherited security attributes are applied to the target file. For example, a file may inherit security attributes (e.g., read, write, view attributes) from the directory in which the file is located or from the directory structure in which the file is located. Such inherited security attributes are not applied to the target file as they are not attributes that are native to the file. [0072] The stub file corresponding to the specified file is then deleted from the original storage location (step 414). The migrated portion of the specified file is deleted from the repository storage location (step 416). If information is stored for migrated files (e.g., file location information 114 in database 112), then the information stored for the specified file is updated to reflect that the stub file and the migrated portion of the specified original file have been deleted (step 418). As part of 418, the file entry in the database may be marked as inactive. [0073] As described above, a migrated file is moved to the specified target storage location without triggering a recall. In this manner, the problems associated with recalls such as increased network traffic that can degrade the performance of the storage environment are avoided. Move operations may be successfully performed even if the original storage unit does not have sufficient storage capacity to store the recalled file data. Further, the requisite databases storing file information are appropriately updated to maintain consistency of the file system. [0074] Various measures may be used to preserve the consistency of the file system due to errors that may occur during the move operation depicted in FIG. 4. For example, at the start of the move operation, the status of the file may be marked as “move in progress”. The original file may be saved in memory for rollback purposes in case or errors that may occur. If any errors occur before the stub file and the migrated data in the repository storage location are deleted, the file status for the original file is rolled back to its original status and the stub file in the original storage location and the migrated data in the repository storage location are left unchanged. If an error occurs after the stub file is deleted but before the repository file data is deleted, the file status for the original file in the database is marked to indicate “pending deleting repository file data”. A background thread then processes this record and deletes the orphaned repository file data. The file location record saved in the database is updated by the background process to reflect the fact that the repository file is deleted. [0075] FIG. 5 is a simplified high-level flowchart 500 depicting a method of deleting a file without performing a recall according to an embodiment of the present invention. The method depicted in FIG. 5 may be performed by software modules executed by a processor, hardware modules, or combinations thereof. Flowchart 500 depicted in FIG. 5 is merely illustrative of an embodiment of the present invention and is not intended to limit the scope of the present invention. Other variations, modifications, and alternatives are also within the scope of the present invention. The method depicted in FIG. 5 may be adapted to work with different implementation constraints. [0076] As depicted in FIG. 5, processing is initiated upon receiving a request to delete a file (step 502). The request may be received responsive to a user action (e.g., the user requests the file to be deleted) or may be received from an application or process. [0077] A determination is then made if the specified file to be deleted has been migrated (step 504). As previously described, such a determination may be made using several techniques. For example, if a stub file is located in place of the actual file, then this indicates that the file has been migrated. Alternatively, information stored for the migrated files (e.g., file location information 114 stored in database 112) may be queried to determine if the specified file to be moved has been migrated. [0078] If it is determined in 504 that the specified file has not been migrated, then the file is deleted (step 506) and this completes the file delete operation. Since the file has not been migrated, no recall operation needs to be performed as a result of the delete operation. [0079] If it is determined in step 504 that the specified file has been migrated, then the location of the migrated portion of the file to be deleted is determined (step 508). As part of 508, the repository storage location and the repository storage unit (e.g., the repository volume) may be determined. As previously described, the location of the migrated file data may be determined from information stored in a stub file corresponding to the specified file to be deleted which is stored in the original storage location of the specified file. The location of the migrated portion of the file may also be determined from file location information 114 stored in database 112. In some embodiments, information in the stub file and the file location information may be used in conjunction to determine the location of the migrated file portion. [0080] A stub file corresponding to the specified file is then deleted from the original storage location (step 510). The migrated file portion is then deleted from the repository storage location determined in step 508 (step 512). If file information is stored for migrated files (e.g., file location information 114 in database 112), then the stored information for the specified file is updated to reflect the deletion of the stub file and the migrated file portion (step 514). [0081] As described above, a migrated file is deleted without triggering a recall. In this manner, problems associated with recalls such as increased network traffic that can degrade the performance of the storage environment are avoided. Delete operations may be successfully performed even if the original storage unit does not have sufficient storage capacity to store the recalled file data. Further, the requisite databases storing file information are appropriately updated to maintain consistency of the file system. [0082] Various measures may be used to preserve the consistency of the file system due to errors that may occur during the delete operation. For example, at the start of the delete operation, the status of the file may be marked as “delete in progress”. The original file may be saved in memory for rollback purposes in case or errors that may occur. If any errors occur before the stub file and the migrated data in the repository storage location are deleted, the file status for the original file is rolled back to its original status and the stub file and the migrated data in the repository storage location are left unchanged. If an error occurs after the stub file is deleted but before the repository file data is deleted, the file status for the original file in the database is marked to indicate “pending deleting repository file data”. A background thread then processes this record and deletes the orphaned repository file data. The file location record saved in the database is updated by the background process to reflect the fact that the repository file is deleted. [0083] As described above, embodiments of the present invention perform file operations on migrated files such as moving a file, copying a file, and deleting a file without triggering a recall. These operations are accordingly performed without burdening network traffic. Further, lack of sufficient space on the original storage unit to store the recalled migrated data does not cause the file operations to fail. This is particularly useful in storage environments with large file sizes. [0084] The techniques described above can be used in any storage environment where portions of a file (e.g., the data portion) or the entire file are moved or migrated from the original location of the file to some other location. Examples of such storage environments include environments managed by HSM applications, by ILM applications, and the like. In such storage environments, embodiments of the present invention can be used to perform file operations on migrated files without triggering a recall. Embodiments of the present invention thus improve the efficiency of file operations that are performed in such storage environments while preserving consistency of the file system. [0085] Although specific embodiments of the invention have been described, various modifications, alterations, alternative constructions, and equivalents are also encompassed within the scope of the invention. The described invention is not restricted to operation within certain specific data processing environments, but is free to operate within a plurality of data processing environments. Additionally, although the present invention has been described using a particular series of transactions and steps, it should be apparent to those skilled in the art that the scope of the present invention is not limited to the described series of transactions and steps. [0086] Further, while the present invention has been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. The present invention may be implemented only in hardware, or only in software, or using combinations thereof. [0087] The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that additions, subtractions, deletions, and other modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5053948 *Feb 4, 1991Oct 1, 1991Wisconsin Alumni Research FoundationFile index system for mass storage deviceUS5063523 *Nov 16, 1989Nov 5, 1991Racal Data Communications Inc.Network management system with event rule handlingUS5131087 *Nov 21, 1990Jul 14, 1992Storage Technology CorporationComputer system having apparatus for automatically redistributing data records stored thereinUS5202982 *Mar 27, 1990Apr 13, 1993Sun Microsystems, Inc.Method and apparatus for the naming of database component files to avoid duplication of filesUS5276867 *Dec 19, 1989Jan 4, 1994Epoch Systems, Inc.Digital data storage system with improved data migrationUS5333315 *Jun 27, 1991Jul 26, 1994Digital Equipment CorporationSystem of device independent file directories using a tag between the directories and file descriptors that migrate with the filesUS5367698 *Oct 31, 1991Nov 22, 1994Epoch Systems, Inc.Network file migration systemUS5471677 *Jun 24, 1993Nov 28, 1995Matsushita Electric Industrial Co., Ltd.Data retrieval using user evaluation of data presented to construct interference rules and calculate range of inputs needed for desired output and to formulate retrieval queriesUS5475834 *Oct 26, 1992Dec 12, 1995International Business Machines CorporationIntegration of migration level two and backup tape processing using multiple inventory entriesUS5485606 *Jun 24, 1992Jan 16, 1996Conner Peripherals, Inc.System and method for storing and retrieving files for archival purposesUS5506986 *May 16, 1995Apr 9, 1996Electronic Data Systems CorporationMedia management system using historical data to access data sets from a plurality of data storage devicesUS5606689 *Dec 23, 1992Feb 25, 1997Fujitsu LimitedData processing apparatus including external storage previously reserved to be allocated to job groupsUS5689681 *May 24, 1995Nov 18, 19973Com CorporationSystem for reading dynamically changing data supporting partial reads of storage locationsUS5708806 *Jun 7, 1995Jan 13, 1998Inso Providence CorporationData processing system and method for generating a representation for and for representing electronically published structured documentsUS5778395 *Oct 23, 1995Jul 7, 1998Stac, Inc.System for backing up files from disk volumes on multiple nodes of a computer networkUS5798766 *Oct 15, 1996Aug 25, 1998Fuji Xerox Co., Ltd.Drawing systemUS5819296 *Oct 31, 1996Oct 6, 1998Veritas Software CorporationMethod and apparatus for moving large numbers of data files between computer systems using import and export processes employing a directory of file handlesUS5873103 *Aug 27, 1997Feb 16, 1999Kodak LimitedData storage management for network interconnected processors using transferrable placeholdersUS5933603 *Jun 10, 1996Aug 3, 1999Emc CorporationVideo file server maintaining sliding windows of a video data set in random access memories of stream server computers for immediate video-on-demand service beginning at any specified locationUS5978815 *Jun 13, 1997Nov 2, 1999Microsoft CorporationFile system primitive providing native file system support for remote storageUS5983318 *Sep 28, 1994Nov 9, 1999International Business Machines CorporationMaximizing hit ratio in an automated storage libraryUS5991753 *Jun 14, 1995Nov 23, 1999Lachman Technology, Inc.Method and system for computer file management, including file migration, special handling, and associating extended attributes with filesUS6023709 *Dec 15, 1997Feb 8, 2000International Business Machines CorporationAutomated file error classification and correction in a hierarchical storage management systemUS6035373 *May 20, 1997Mar 7, 2000International Business Machines CorporationMethod for rearranging data in a disk array system when a new disk storage unit is added to the array using a new striping rule and a pointer as a position holder as each block of data is rearrangedUS6038379 *Oct 11, 1995Mar 14, 2000Seagate Technology, Inc.Data backup and restore system for a computer network having generic remote file system agents for providing backup and restore operationsUS6154817 *Dec 16, 1996Nov 28, 2000Cheyenne Software International Sales Corp.Device and method for managing storage mediaUS6269382 *Aug 31, 1998Jul 31, 2001Microsoft CorporationSystems and methods for migration and recall of data from local and remote storageUS6330572 *Jul 15, 1999Dec 11, 2001Imation Corp.Hierarchical data storage managementUS6330610 *Dec 4, 1997Dec 11, 2001Eric E. DocterMulti-stage data filtering system employing multiple filtering criteriaUS6339793 *Apr 6, 1999Jan 15, 2002International Business Machines CorporationRead/write data sharing of DASD data, including byte file system data, in a cluster of multiple data processing systemsUS6366988 *Jul 17, 1998Apr 2, 2002Storactive, Inc.Systems and methods for electronic data storage managementUS6404925 *Mar 11, 1999Jun 11, 2002Fuji Xerox Co., Ltd.Methods and apparatuses for segmenting an audio-visual recording using image similarity searching and audio speaker recognitionUS6415280 *Apr 1, 1999Jul 2, 2002Kinetech, Inc.Identifying and requesting data in network using identifiers which are based on contents of dataUS6449731 *Aug 17, 1999Sep 10, 2002Tricord Systems, Inc.Self-healing computer system storageUS6453325 *Feb 3, 1997Sep 17, 2002International Business Machines CorporationMethod and means for backup and restoration of a database system linked to a system for filing dataUS6460070 *Jun 3, 1998Oct 1, 2002International Business Machines CorporationMobile agents for fault diagnosis and correction in a distributed computer environmentUS6493756 *Jan 31, 2000Dec 10, 2002Networks Associates, Inc.System and method for dynamically sensing an asynchronous network event within a modular framework for network event processingUS6519637 *Sep 23, 1999Feb 11, 2003International Business Machines CorporationMethod and apparatus for managing a memory shortage situation in a data processing systemUS6584497 *Jul 28, 1999Jun 24, 2003International Business Machines CorporationMethod, system, and program for returning a file requested through a network connectionUS6631477 *Mar 13, 1998Oct 7, 2003Emc CorporationHost system for mass storage business continuance volumesUS20010034795 *Feb 5, 2001Oct 25, 2001Moulton Gregory HaganSystem and method for intelligent, globally distributed network storageUS20010037475 *Mar 22, 2001Nov 1, 2001Robert BradshawMethod of and apparatus for recovery of in-progress changes made in a software applicationUS20020138251 *May 22, 2001Sep 26, 2002Geary Michael DavidAutomated astrological data retrieval and analysisUS20020174139 *May 21, 2002Nov 21, 2002Christopher MidgleySystems and methods for backing up data filesUS20030046270 *Aug 30, 2002Mar 6, 2003Arkivio, Inc.Techniques for storing data based upon storage policiesUS20030046313 *Aug 26, 2002Mar 6, 2003Arkivio, Inc.Techniques for restoring data based on contents and attributes of the dataUS20030115204 *Apr 25, 2002Jun 19, 2003Arkivio, Inc.Structure of policy information for storage, network and data management applicationsUS20040039891 *Aug 27, 2003Feb 26, 2004Arkivio, Inc.Optimizing storage capacity utilization based upon data storage costsUS20040049513 *Aug 27, 2003Mar 11, 2004Arkivio, Inc.Techniques for moving stub files without recalling dataUS20040054656 *Aug 27, 2003Mar 18, 2004Arkivio, Inc.Techniques for balancing capacity utilization in a storage environmentUS20040083202 *Aug 30, 2002Apr 29, 2004Arkivio, Inc.Techniques to control recalls in storage management applicationsUS20040163029 *Dec 1, 2003Aug 19, 2004Arkivio, Inc.Data recovery techniques in storage systemsUS20050021566 *May 28, 2004Jan 27, 2005Arkivio, Inc.Techniques for facilitating backup and restore of migrated filesUS20050033757 *Jun 24, 2004Feb 10, 2005Arkivio, Inc.Techniques for performing policy automated operations* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7092977Aug 30, 2002Aug 15, 2006Arkivio, Inc.Techniques for storing data based upon storage policiesUS7509316Jun 24, 2004Mar 24, 2009Rocket Software, Inc.Techniques for performing policy automated operationsUS7660837Feb 9, 2010Broadcom CorporationMethod for automatically managing disk fragmentationUS7765244 *Jul 27, 2010Broadcom CorporationFast and efficient method for deleting very large files from a filesystemUS7801871Aug 9, 2006Sep 21, 2010Nexsan Technologies Canada Inc.Data archiving systemUS7860896Jan 12, 2010Dec 28, 2010Broadcom CorporationMethod for automatically managing disk fragmentationUS7966351Jul 26, 2010Jun 21, 2011Broadcom CorporationFast and efficient method for deleting very large files from a filesystemUS8086578Dec 27, 2011Nexsan Technologies Canada Inc.Data archiving systemUS8683484 *Jul 23, 2009Mar 25, 2014Novell, Inc.Intelligently pre-placing data for local consumption by workloads in a virtual computing environmentUS8843461Dec 12, 2011Sep 23, 2014Nexsan Technologies Canada Inc.Data archiving systemUS8892507 *Jul 9, 2013Nov 18, 2014Emc CorporationProviding file system quota support for a file system having separated data and metadataUS8935210Apr 25, 2014Jan 13, 2015Commvault Systems, Inc.Systems and methods for performing replication copy storage operationsUS9002785 *Jul 31, 2013Apr 7, 2015Commvault Systems, Inc.Stubbing systems and methods in a data replication environmentUS9002799Feb 14, 2014Apr 7, 2015Commvault Systems, Inc.Systems and methods for resynchronizing informationUS9003374May 5, 2014Apr 7, 2015Commvault Systems, Inc.Systems and methods for continuous data replicationUS9020898Jul 9, 2014Apr 28, 2015Commvault Systems, Inc.Systems and methods for performing data replicationUS9031899 *Dec 7, 2007May 12, 2015Brocade Communications Systems, Inc.Migration in a distributed file systemUS9047357Feb 28, 2014Jun 2, 2015Commvault Systems, Inc.Systems and methods for managing replicated database data in dirty and clean shutdown statesUS9069779 *Dec 7, 2007Jun 30, 2015Brocade Communications Systems, Inc.Open file migration operations in a distributed file systemUS9208210Dec 23, 2013Dec 8, 2015Commvault Systems, Inc.Rolling cache configuration for a data replication systemUS9298382Jan 8, 2015Mar 29, 2016Commvault Systems, Inc.Systems and methods for performing replication copy storage operationsUS9323758 *Dec 22, 2009Apr 26, 2016Emc CorporationEfficient migration of replicated files from a file server having a file de-duplication facilityUS20030046270 *Aug 30, 2002Mar 6, 2003Arkivio, Inc.Techniques for storing data based upon storage policiesUS20030046313 *Aug 26, 2002Mar 6, 2003Arkivio, Inc.Techniques for restoring data based on contents and attributes of the dataUS20030115204 *Apr 25, 2002Jun 19, 2003Arkivio, Inc.Structure of policy information for storage, network and data management applicationsUS20040039891 *Aug 27, 2003Feb 26, 2004Arkivio, Inc.Optimizing storage capacity utilization based upon data storage costsUS20040049513 *Aug 27, 2003Mar 11, 2004Arkivio, Inc.Techniques for moving stub files without recalling dataUS20040054656 *Aug 27, 2003Mar 18, 2004Arkivio, Inc.Techniques for balancing capacity utilization in a storage environmentUS20040163029 *Dec 1, 2003Aug 19, 2004Arkivio, Inc.Data recovery techniques in storage systemsUS20050021566 *May 28, 2004Jan 27, 2005Arkivio, Inc.Techniques for facilitating backup and restore of migrated filesUS20050033757 *Jun 24, 2004Feb 10, 2005Arkivio, Inc.Techniques for performing policy automated operationsUS20050216532 *Mar 24, 2004Sep 29, 2005Lallier John CSystem and method for file migrationUS20070028231 *Aug 1, 2005Feb 1, 2007International Business Machines CorporationSystem and method for start menu and application uninstall synchronizationUS20070288430 *Dec 5, 2006Dec 13, 2007Arkivio, Inc.Techniques to Control Recalls in Storage Management ApplicationsUS20080005205 *Oct 6, 2006Jan 3, 2008Broadcom CorporationFast and efficient method for deleting very large files from a filesystemUS20080005206 *Oct 6, 2006Jan 3, 2008Broadcom CorporationMethod for automatically managing disk fragmentationUS20090150449 *Dec 7, 2007Jun 11, 2009Brocade Communications Systems, Inc.Open file migration operations in a distributed file systemUS20090150460 *Dec 7, 2007Jun 11, 2009Brocade Communications Systems, Inc.Migration in a distributed file systemUS20090150462 *Dec 7, 2007Jun 11, 2009Brocade Communications Systems, Inc.Data migration operations in a distributed file systemUS20100290755 *Nov 18, 2010Broadcom CorporationFast and efficient method for deleting very large files from a filesystemUS20100299315 *Aug 6, 2010Nov 25, 2010Nexsan Technologies Canada Inc.Data archiving systemUS20110023048 *Jul 23, 2009Jan 27, 2011Srinivasan Kattiganehalli YIntelligent data placement and management in virtual computing environmentsUS20130191354 *Jul 25, 2012Jul 25, 2013Verint Systems Ltd.System and Method for Information Lifecycle Management of Investigation CasesUS20140067764 *Jul 31, 2013Mar 6, 2014Commvault Systems, Inc.Stubbing systems and methods in a data replication environment* Cited by examinerClassifications U.S. Classification1/1, 707/E17.01, 707/999.2International ClassificationG06F17/30Cooperative ClassificationG06F17/30067European ClassificationG06F17/30FLegal EventsDateCodeEventDescriptionOct 4, 2004ASAssignmentOwner name: ARKIVIO, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CHENG, WEN;KAUSHIK, RINI;GREWAL, BOB;REEL/FRAME:015846/0471Effective date: 20040813RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services