Multiple contexts in a redirect on write file system

The present invention relates generally to the field of computers, and more specifically to data backup in redirect-on-write file systems.

The file system uses various methods to ensure its internal consistency in the event of a system crash. One approach is for the file system to write change data to new locations on disk in bottom-up order every few seconds. These views of the data stored inside it are called consistent snapshots. After a system crash, the file system boots from the top of the last consistent snapshot of the file system, which is guaranteed to be consistent.

<p num="0003"> While the consistency snapshot is being written, the user may try to modify the file system. It would be easy to block such modifications until the consistency snapshot was committed for storage on a non-volatile machine-readable medium (eg, hard disk). However, this approach is unacceptable. This is because such an approach would make the consistent snapshot opaque to the user. In particular, this approach can freeze the entire file system every few seconds while a consistent snapshot is committed for memory.</p>

<p num="0004"> An embodiment of the invention is to initiate a commit to store the current consistent snapshot of a plurality of data objects in a redirect-on-write file system on a non-volatile machine-readable medium. Each of the plurality of data objects has a context in which it is being committed, has a first copy of the data of the plurality of data objects, includes methods including starting. The method also includes giving the current consistency snapshot a generation value that is unique to the generation value of the other consistency snapshot. The method involves receiving updates to a data object of multiple data objects while committing to remember the current consistency snapshot. The method also includes incrementing the generation value for the data object in response to receiving updates to the data object. The method involves associating a generation value derived from a generation value of a data object with the update in response to receiving an update for the data object. Similarly, in response to receiving updates to the data object, the method is to make a second copy of the data object's data, which is copied from the first copy of the data object's data. Including. The second copy of the data in the data object has the context being updated. Similarly, in response to receiving an update to the data object, the method is independent of updating the first copy of the data of the data object, and the second of the data of the data object based on the update. Includes updating a copy of.</p><p num="0005"> An embodiment of the invention is to initiate a commit to permanently store the current consistency snapshots of a plurality of data objects in a redirect-on-write file system. Each of the data objects includes methods, including starting, which can be configured to have multiple copies of the data of a plurality of data objects, having different contexts. Each of the plurality of data objects has a first copy of at least two copies of the data, having a first context of at least two contexts. The method involves receiving updates to a data object of multiple data objects while committing to remember the current consistency snapshot. In response to receiving updates to the data object, the method comprises making a second copy of the data object's data from the first copy. The second copy of the data has a second of at least two contexts. In response to receiving an update to the data object, the method also includes updating a second copy of the data in the data object based on the update.</p>

<figref num="1">FIG. 5 is a conceptual diagram of a clustered file system configuration that provides multiple contexts for data objects in a redirect-on-write file system, according to some embodiments.</figref><figref num="2">It is a more detailed conceptual diagram of a clustered file system configuration that provides multiple contexts for data objects in a redirect-on-write file system, according to some embodiments.</figref><figref num="3">It is a figure which shows the example of the buffer header for the data object stored in a clustered file system by some embodiments.</figref><figref num="4">FIG. 5 illustrates an example of a timeline that commits a consistent snapshot to multiple generations of a data object, according to some embodiments.</figref><figref num="5">It is a flowchart of the work which provides a plurality of contexts for a data object in a redirect-on-write file system according to some embodiments.</figref><figref num="6">It is a flowchart of the work which provides a plurality of contexts for a data object in a redirect-on-write file system according to some embodiments.</figref><figref num="7">It is a figure which shows the example of the computer system.</figref>

It is hoped that this embodiment will be better understood by reference to the accompanying drawings and a number of objects, features and advantages will be apparent to those skilled in the art.

Subsequent descriptions include examples of systems, methods, techniques, instruction sequences and computer programs that embody the techniques of the subject matter of the invention. However, it will be appreciated that the embodiments described may be implemented without these specific details. For example, while the example refers to dual contexts for data that are part of a file system, some other embodiment examples have any number of contexts for data (eg, three, It can be configured (4, 5, etc.). Similarly, while it is described as creating a consistent snapshot for the file system, in some other embodiments, a consistent snapshot at another level can be created. .. For example, a user can configure a subset of files, specific files, etc. to be backed up within a consistent snapshot more often than regular snapshots for the file system. Therefore, some embodiments are applicable to these other levels of consistency snapshots. In other examples, well-known instruction instances, protocols, structures and techniques are not shown in detail so as not to obscure the description.

Clusters are formed from multiple computer systems or nodes, as well as resources, including persistent storage resources. A clustered file system is implemented across the cluster's storage resources. Cluster storage resources are combined to allow direct access by the nodes of the cluster. Storage resources can be cabled directly to the node, made accessible via a network (eg, a storage area network), or both methods can be used.

Once the cluster is established, the administrator configures one of the nodes in the cluster to act as the cluster leader. Embodiments can also program the cluster to automatically choose a reader. The cluster reader holds cluster role data that indicates whether the node is a client or a server, or both a client and a server. The server manages the filesets in the clustered file system. The cluster reader also holds instructions on which node acts as the clustered file system manager. The Clustered File System Manager manages the metadata for the clustered file system. In some embodiments, the clustered file system manager is the only server for the cluster-not responsible for the failover server. In some embodiments, the clustered file system manager delegates the management of the filesets in the clustered file system to other nodes that are servers. As used herein, the term "file set" is used to refer to a set of files and / or a set of directories. Along with instructions on which nodes are servers in the cluster, the cluster reader can hold instructions for filesets managed by the server or "fileset manager". Nodes in the cluster can be configured to act as cluster leaders and clustered file system managers. Whether a node acts as a cluster leader, a server, a client, or something else can be transparent to the users of the cluster. Whether the node acts as both a client and a server, or the client is on a remote node, the user will perceive the same behavior.

The clustered file system manager can maintain metadata as an inode hierarchy for files in the clustered file system. Clustered file system metadata provides information about the logical units of storage for clustered storage resources. The information can include the location of the cluster storage unit (eg, offset or block number) as well as the length of the extent. In this description, the term "block" is used to refer to a unit of cluster storage (eg, 4KB block). The description also uses the term "extent" to refer to a set of adjacent blocks. When referring to the "length" of an extent, the length refers to a number of adjacent blocks that form the extent. Using these terms, assuming 4KB blocks, the clustered file system considers a pool of storage resources totaling 10GB to be 0 to 2,621,439 blocks. When a cluster client writes to a logical unit in cluster storage, the logical unit (eg, block number) is converted to a physical location (eg, seek and offset) by the storage virtualization layer to fulfill the write. The embodiment is not limited to blocks and extents, but it can be confusing given any possible implementation of cluster storage units (eg, variable length blocks, bit lengths, etc.). Let's go.

In some embodiments, the clustered file system manager keeps the clustered file system metadata (metadata) within the hierarchical data structure of the inode. The clustered file system manager keeps the route for metadata in a known location (ie, in place) within the cluster storage resource (cluster storage). Within a cluster that supports consistent snapshots, multiple locations in cluster storage are reserved or defined to store the roots of the consistent snapshots along with the corresponding consistent snapshot root metadata. Root metadata helps identify consistent snapshots and ensure the integrity of consistent snapshots. The embodiment can use a time-based identifier (eg, generation value) of the consistency snapshot to track the progress of the consistency snapshot, and a root checksum to check the integrity of the data. An embodiment writes a first root checksum (header checksum) when a node begins writing a route, and after the route has been successfully written to persistent cluster memory, a second root checksum. ("Trailer checksum") can be written. The embodiment can use a header checksum and a trailer checksum to ensure that the writing of the root of the consistency snapshot was not interrupted. To recover from a failure, each of the locations is examined, the location with the latest generation value is selected, and it is possible to start recovery from that consistent snapshot referenced by the selected location. In the embodiment, the cluster can be configured to store any number of consistent snapshots.

Some embodiments provide consistent snapshots of the data in a given file system, but such snapshots come in while the consistent snapshot is committed for storage. Do not block or delay incoming file system transactions. Therefore, updates to the data stored in the file system can occur at the same time as the storage of consistent snapshots of the same file system. As further described below, at least two contexts for the same data object are retained to allow this concurrency.

File system consistency snapshots are associated with unique generation values. For example, the generation value can be an integer value. Therefore, once a commit to store a consistent snapshot (ie, synchronization of that consistent snapshot) is initiated, the generation for the file system can be incremented.

In some embodiments, any changes to objects (eg, data, files, etc.) in the file system are associated with the transaction. Transactions are associated with file system generations and thus with consistent snapshots. In some embodiments of the dual context configuration, the objects in the file system are always cached with up to two copies of the objects. One copy is for the context being updated. In particular, the updating context for an object is for remembering a consistent snapshot of the file system that holds the object after the object was being updated (for example, the user updated the object). Created while being committed to. The second copy of the object is for the context being committed. This copy of the object is a copy of the object that is being / will be committed for memory as part of a consistency snapshot. In some embodiments, the two objects can be cached together as a size 2 array. Similarly, an object has an array of two elements that stores the generation associated with each object in the array.

In some embodiments, the generation value or generation number associated with a transaction is compared to the cached object's generation number to determine which context of the object to use. The correct object array element is selected to change the correct context of the object (for example, the context being updated or the context being committed).

Consistency snapshots are taken on a regular basis (eg, every 5 seconds), as described further below. These consistency snapshots are created to attempt to recover an earlier version of the object. For example, these consistent snapshots can be used to recover objects stored in the file system after a system crash. In some embodiments, if the consistency snapshot interval is reached before the previous consistency snapshot finishes its synchronization (commit for memory), the new consistency snapshot is skipped. In particular, then a third copy of the cached object would be needed, so a consistent snapshot would not be taken.

FIG. 1 shows a conceptual diagram of a clustered file system configuration that provides multiple contexts for data objects in a redirect-on-write file system, according to some embodiments. The illustrated cluster includes nodes 103, 105, 107, 109. The cluster also includes a pool of directly accessible storage devices 101, network accessible storage devices 113, 115, and network infrastructure 111. Nodes 103, 105, 107, 109 communicate via the network infrastructure 111. Nodes 103, 105, 107, 109 access the storage device pool 101 via cables and access network accessible storage devices 113, 115 via the network infrastructure 111. In the cluster shown, any of nodes 103, 105, 107, 109 can be configured as a clustered file system manager for the cluster. The Clustered File System Manager can manage various aspects of the file storage of its internal clustered file system. For example, the clustered file system manager can hold metadata as an inode hierarchy for files in a clustered file system. In some embodiments, some or all of the work of the clustered file system manager can be assigned to different nodes 103, 105, 107, 109. Some of these tasks include tasks related to providing multiple contexts for data objects in a clustered file system (as described further below). In the following, these tasks of providing multiple contexts for a data object are described to be distributed across different nodes 103, 105, 107, 109, while some other embodiments.

FIG. 2 shows a more detailed conceptual diagram of a clustered file system configuration that provides multiple contexts for data objects in a redirect-on-write file system, according to some embodiments. FIG. 2 shows a system 200 including node A 202, node B 204 and node N 206 which can represent nodes 103, 105, 107 and 109 of FIG. FIG. 2 shows a number of components within node A 202. Although not shown, Node B 204 and Node N 206 may contain similar components within them.

In some embodiments, the system 200 is configured to store data objects in a file system that use redirect-on-write (ROW) when data is modified. In particular, redirect on write allocates new blocks for change data. A file system can contain one or more file sets. In some embodiments, each file in the file system may include an inode. An inode can be a separate file or data structure that stores information or metadata about the data stored in the file. For example, for each part of the file (eg, a block), the inode can store the address, fileset identification information, and generation of the fileset in which this data is stored. In particular, the blocks in which file data is stored can be distributed across different file sets and generations of file sets. Different file sets, and file set generations, can be distributed across multiple storage devices. With reference to FIG. 2, these file sets can be stored on a machine-readable medium at any of node A 202, node B 204 and node N 206.

System 200 includes a number of client devices (shown as client device 208 and client device 210). System 200 includes network 212, and node A 202, node B 204, node N 206, client device 208 and client device 210 are communicably coupled together through network 212.

Node A 202 includes a fileset manager 214, a non-volatile machine-readable medium 216, and a memory (eg, a volatile machine-readable medium) 218 communicably coupled together. Fileset Manager 214 can be software, firmware, hardware or a combination thereof. For example, Fileset Manager 214 can be part of an operating system running on a processor (not shown) in Node A 202. The non-volatile machine-readable medium 216 contains a number of consistent snapshots already created (Consistency Snapshot A 224 and Consistency Snapshot N). (Shown as 226) is stored. The non-volatile machine-readable medium 216 is also in the process of storing the current consistency snapshot 228, which is in the process of being committed for storage within it. In some embodiments, consistent snapshots are taken periodically (eg, every 5 seconds). Consistency snapshots include snapshots of data objects in the file system at a given point in time. In some embodiments, the consistency snapshot is in memory 218, which is not yet committed for storage on a non-volatile machine-readable medium 216 after the last consistency snapshot was committed for storage. Remember any changes (eg, modifications, additions, deletions, etc.) to a data object in. These consistent snapshots are created to attempt to recover an earlier version of an object stored in the file system. For example, these consistent snapshots can be used to recover objects stored in the file system after a system crash.

Memory 218 has a large number of buffer headers (buffer header A 220, buffer header N). 222 etc.) is memorized. As further described below (see description in FIG. 3), the buffer header stores various metadata about the data objects stored in the file system. If the data object is being accessed, modified, etc., Fileset Manager 214 creates a buffer header for the data object in memory 218 (still created in it). If not). For example, the file set manager 214 may be accessing a data object to create the current consistency snapshot 228, modifying the data object based on some client device request, and so on. You can also create a buffer header. Based on the size of memory 218 and the number of data objects being accessed, Fileset Manager 214 is prompted to flush some of the buffer headers that the relevant data objects are not in the process of being accessed. You can do it. Accordingly, the fileset manager 214 may be asked to recreate the buffer header for the data object in memory 218 when the data object is accessed. As further described below, the metadata in the buffer header stores data pointers for different copies of the data created for a given data object. In this example, buffer header A 220 has a first data pointer pointing to a first copy 250 of data and a second data pointer pointing to a second copy 252 of data. Similar data pointers can be created for different buffer headers stored in memory 218.

In some embodiments, multiple copies of the data for the same data object in the file system are created. Each of the multiple copies of data can be associated with a different context. In some embodiments, the data object may have two copies of its data for dual context configuration. As an example, memory 218 stores two copies of data for the same data object: a first copy of data 250 and a second copy of data 252. Any or all data objects stored in the file system can include this multi-copy, multi-context configuration. As shown, the first copy 250 of the data has a context 254 being committed and the second copy 252 of the data has a context 256 being updated. Two contexts for the same data object provide a consistent snapshot of the data in the file system, but such a snapshot is entered while the consistent snapshot is committed for memory. Do not block or delay incoming file system transactions. Therefore, updates to the data stored in the file system can occur at the same time as the storage of consistent snapshots of the same file system. Specifically, the context 254 being committed is associated with a copy of the data used to create this particular data object within the current consistency snapshot 228. Context 256 being updated is an update to a data object (eg, user data) while the current consistency snapshot 228 is committed for storage (created in non-volatile machine-readable medium 216). Is associated with a copy of the data used to accept (changes to).

FIG. 2 also shows a number of tasks (work 230, work 232 and work 234). In this example, the fileset manager 214 performs work 230, in which the fileset manager 214 initiates a commit to store the current consistency snapshot. In particular, Fileset Manager 214 begins creating the current consistency snapshot 228. As part of the work, Fileset Manager 214 can determine what data objects have changed since the previous consistency snapshot was committed for memory. Fileset Manager 214 can then write the modified data objects to new locations within the non-volatile machine-readable medium 216 in bottom-up order. In some embodiments, for each data object stored in the current consistency snapshot 228, Fileset Manager 214 creates and / or updates the associated buffer header in memory 218. Can be performed (shown as work 234). If there is no associated buffer header for the data object in memory 218, Fileset Manager 214 is in the process of accessing such data for storage in the current consistency snapshot 228. Create a buffer header in. As further described below with reference to FIGS. 4-6, the buffer header for each data object contains various metadata (eg, generation, context, position, data pointer). Fileset Manager 214 updates this metadata as part of creating a buffer header in memory 218. Alternatively, if the buffer header is already instantiated in memory 218 for a given data object, Fileset Manager 214 can update the metadata in it. For example, Fileset Manager 214

Similarly, the data objects that should be contained within the current consistency snapshot 228 are modified prior to the completion of the commit to remember the current consistency snapshot 228. In this example, client device 210 sends an update request for a data object that is part of the current consistency snapshot 228 over network 212, and the update request is received by fileset manager 214. (Shown as work 232). In this situation, Fileset Manager 214 makes a second copy of the data in the data object that is copied from the first copy of the data (eg, the first copy 250 of the data and the second copy of the data). See copy 252). Similarly, the second copy of the data has a context that is separate and different from the context defined for the first copy of the data. In some embodiments, a second copy of the data is not made until a second copy is needed to provide dual context. For example, while a consistent snapshot that stores the same data object is being created, Fileset Manager 214 does not make a second copy until an update to the data object is requested. Similarly, Fileset Manager 214 creates and / or updates buffer headers for this data object in memory 218. For example, Fileset Manager 214 may update the second data pointer in the buffer header to point to a second copy of the data. Similarly, Fileset Manager 214 updates the context so that two different copies of the data have two different contexts. A more detailed description of Fileset Manager 214's work of providing multiple contexts for data objects is described below with reference to the flowcharts of FIGS. 5-6.

FIG. 3 shows an example of a buffer header for a data object stored in a clustered file system, according to some embodiments. The buffer header 300 contains a number of fields associated with the data objects stored within the clustered file system. As mentioned above, a buffer header for the data object is created in memory if it is not already in memory and in response to access to the data object. For example, Fileset Manager 214 can access data objects to store them in a consistent snapshot. In another example, the fileset manager 214 can access the data object in response to any application that updates the data object (eg, client devices 208, 210). In addition to creating buffer headers, Fileset Manager 214 can also store data in its internal fields (302-316). Fields 302-304 define two different generation values for this data object. The Last Committed Generation (LCG) field 302 defines the generation value for this data object at the last time this data object was committed for storage in a consistent snapshot. To do. Last updated generation (Last Updated) The Generation, LUG) field 304 defines a generation value for this data object at the last time it was updated. The data object's generation value is incremented each time the data object is first updated, but before the data object is committed for persistent storage as part of a consistent snapshot. .. For example, suppose the current generation value of the data object is 15. If any application attempts to update the data object after the data object has been committed for persistent storage as part of a consistent snapshot, the generation value is incremented to 16. This generation value of this data object remains at 16 until the data object is committed for persistent storage as part of a consistent snapshot.

Fields 306-308 define two different context values for this data object. These context values are set to either 0 or 1. In particular, the context for the data object is inverted between the two values (because it is part of the dual context). Last committed context (LCX) field 306 defines the context for this data object at the last time this data object was committed for storage in a consistent snapshot. .. Last updated context (Last Updated) The Contact, LUX) field 308 defines the context for this data object at the last time it was updated. For example, after the data object has been committed for persistent storage as part of a consistent snapshot, but before the update to the data object, both LCX fields 306 and LUX308 have the same value (eg, for example). It is set to 1). The LUX field 308 is then inverted to a value of 0 when any application attempts to update the data object. The LCX field 306 is then inverted to a value of 0 when this data object is again committed for persistent storage as part of a consistent snapshot. The use of fields 302-308 is further described below with reference to the flowcharts of FIGS. 5-6.

The physical position field 310 defines the physical position (eg, block number) of a data object in the file system. The logical position field 312 defines the logical position where the data object is stored based on the position of the associated inode for this data object. For example, the logical position can include the physical position of some offset in addition to the inode where this data object is stored.

The data pointer 0 field 314 stores a first data pointer (data pointer 0) pointing to a first copy of the data of the data object in memory 218. The data pointer 1 field 316 stores a second data pointer (data pointer 1) pointing to a second copy of the data of the data object in memory 218. As mentioned above, a second copy of the data in the data object is not made until a second context for the data object is needed. For example, a copy of a data object's data is after the data object has been committed for persistent storage as part of a consistent snapshot, but before any subsequent updates to the data object. Only one can be provided. In this situation, the data pointer 0 field 314 (pointing to the first copy of the data) points to the first copy of the data and the data pointer 1 field 316 (pointing to the second copy of the data) is in position. Does not point to (eg, NULL). A second copy of the data is made from a copy of the first copy of the data after a second context is needed for the data object. For example, suppose a data object is being stored in a consistent snapshot and at the same time a client device is requesting an update to the data object. In this situation, a second copy of the data object is made. Similarly, the data pointer 0 field 314 (pointing to the first copy of the data) still points to the first copy of the data, and the data pointer 1 field 316 (pointing to the second copy of the data) This time it is modified to point to a second copy of the data in the data object. The use of fields 314-316 is further described below with reference to the flowcharts of FIGS. 5-6.

FIG. 4 shows an example of a timeline that commits a consistent snapshot to multiple generations of a data object, according to some embodiments. Timeline 400 increases in time from left to right. Time point 402 is the time when the generation N for the data object ends. Time point 404 is a later time when a later generation (generation N + 1) for the same data object has ended. Time point 406 is a later time when a later generation (generation N + 2) for the same data object has ended. Period 408 is the period during which a consistent snapshot (including data objects) is committed for persistent storage. Period 408 begins at time point 402 after the end of generation N. As mentioned above as part of the commit, Fileset Manager 214 traverses the data object hierarchy in bottom-up order and collects the block numbers and checksums of the child data objects. As shown, within period 408 there are two sub-periods-period 410 and period 421-. Period 410 includes the period during which one copy or version of the data object remains in memory. For example, this period is the time during which the data object is being committed for persistent storage, and the data object has not yet changed (for example, by an application running on the client device). , Can include time. Period 412 includes the period during which two copies or versions of the data object remain in memory. Period 412 begins in response to changes in the data object while the commit of the consistency snapshot for generation N is still taking place. For example, this period is the time during which the data object is being committed for persistent storage and the data object is being modified (eg, by an application running on the client device). Can include. In other words, de The first version of the data object exists as part of a generation N consistency snapshot that is being published. A second version of the data object is in case or as a result of a write to the data object within the current generation N + 1 prior to the completion of the issuance of the generation N consistency snapshot. It exists because of or both.

Figures 5-6 show flowcharts of work that provides multiple contexts for data objects in a redirect-on-write file system, according to some example embodiments. FIG. 5 shows a flowchart 500, and FIG. 6 shows a flowchart 600. Flowchart 600 is a continuation of Flowchart 500 and transitions at point A. Flowcharts 500-600 are described as being performed in a distributed configuration, where fileset manager 214 performs its internal work. In some other embodiments, the work of flowcharts 500-600 is performed in a centralized configuration, where the file system manager can perform such work. Flowcharts 500-600 show examples of situations where dual context is required for data objects. In particular, in this example situation, a consistent snapshot containing a particular data object (called "Data Object A") is being committed for storage in a non-volatile machine-readable medium. .. This is because data object A has been modified since the previous consistency snapshot was committed for memory. At the same time that this consistency snapshot is committed for memory, there is work to make further changes to data object A. For example, an application running on a client device can modify data object A. The operations of flowcharts 500 to 600 are described with reference to FIGS. 1 to 3. Flowchart 500 is first described, followed by Flowchart 600.

Fileset Manager 214 initiates a commit to store the current consistent snapshot containing a large number of data objects in the file system on a non-volatile machine-readable medium (502). In some embodiments, Fileset Manager 214 commits periodically to remember the current consistency snapshot (eg, 3 seconds, 5 seconds, 10 seconds, etc.). Therefore, this task can be one of the regular tasks of creating a consistent snapshot. Referring to FIG. 2, Fileset Manager 214 initiates a commit to store the current consistency snapshot 228. In some embodiments, the current consistency snapshot 228 will include data objects that have been modified after the previous consistency snapshot. Those modifications to the data object can reside in memory 218, so the modifications have not yet been committed for storage in the non-volatile machine-readable medium 216. The work of Flowchart 500 continues at 504.

Fileset Manager 214 determines if there is a buffer header in memory for the data objects that should be stored in the current consistency snapshot (504). With reference to FIG. 2, fileset manager 214 determines if there is a buffer header in memory 218 for the data object that should be stored in the current consistency snapshot 228. In particular, in some embodiments, the associated buffer header is created in memory 218 each time the data object is accessed (read, written, etc.). If the buffer header for each data object to be stored in the current consistency snapshot 228 is already in memory, the work of Flowchart 500 continues at 508. Otherwise, the work of Flowchart 500 continues at 506.

Fileset Manager 214 creates and updates buffer headers in memory (for data objects that do not yet have buffer headers in memory) (506). Referring to FIG. 2, fileset manager 214 creates buffer headers in memory 218 for those data objects that do not have buffer headers in memory. Fileset Manager 214 can also update the fields in the buffer header. With reference to FIG. 3, Fileset Manager 214 sets the values of these fields for the buffer headers for each of these data objects. Fileset manager 214 sets both LCG field 302 and LUG field 304 to the current generation value for the data object. For example, if the last committed consistency snapshot had a value of 5, Fileset Manager 214 would set LCG field 302 and LUG field 304 to 5. The context fields (306, 308) are set to either 0 or 1 to distinguish between the two contexts (the context being committed and the context being updated). Therefore, if a second context is needed, these two context fields 306, 308 will have opposite values. If only one context is needed, these two context fields 306, 308 will have the same value. In this situation, only one context is needed for the data object. Therefore, the fileset manager 214 sets the LCX field 306 and the LUX field 308 to the same value (eg 1). Fileset manager 214 sets the physical location field 310 based on the location (eg, block number) of the data object in the file system. Fileset manager 21 4 sets the logical position field 312 based on the position of the associated inode for this data object. For example, the logical position can include the physical position of some offset in addition to the inode where this data object is stored. Fileset manager 214 updates data pointer 0 field 314 in buffer header 300 to point to a location in memory 218 where the first copy of data is located. No second data object is needed because this situation does not require multiple contexts. Therefore, the fileset manager 214 updates the data pointer 1 field 316 to point to null. The work of Flowchart 500 continues at 508.

Fileset Manager 214 receives a transaction that updates data object A in the file system, which is part of the data object that should be part of the current consistency snapshot (current consistency). (While a commit to remember the snapshot is still in progress) (508). Referring to FIG. 2, fileset manager 214 receives a transaction from one of client devices 208, 210 to update data object A. For example, an application running on one of client devices 208, 210 can update data object A. The work of Flowchart 500 continues at 510.

Fileset manager 214 determines if there is a buffer header for data object A in memory (510). With reference to FIG. 2, fileset manager 214 determines if there is a buffer header for data object A in memory 218. In particular, in some embodiments, the associated buffer header is created in memory 218 each time the data object is accessed (read, written, etc.). If there is already a buffer header for data object A in memory 218, the work of flowchart 500 continues at continuation point A (518). Otherwise, the work of Flowchart 500 continues at 512.

Fileset manager 214 creates a buffer header in memory for data object A (512). Referring to FIG. 2, fileset manager 214 creates a buffer header in memory 218 for data object A. This is because there is no associated buffer header in memory 218 for data object A. Fileset Manager 214 can also store data in fields in the buffer header (as described further by the work below). The work of Flowchart 500 continues at 514.

Fileset manager 214 updates the data pointer 0 field in the buffer header for data object A (514). With reference to FIGS. 2-3, the fileset manager 214 updates the data pointer 0 field 314 in the buffer header 300 to point to a location in memory 218 where the first copy of the data is located. To do. The work of Flowchart 500 continues at 516.

Fileset Manager 214 also updates the physical position, logical position, LCG and LCX fields in the buffer header for data object A. With reference to FIGS. 2-3, the fileset manager 214 updates the physical position field 310, the logical position field 312, the LCG field 302, and the LCX field 306 for the buffer header 300. Fileset manager 214 sets the physical location field 310 based on the location (eg, block number) of the data object in the file system. Fileset Manager 214 sets the logical position field 312 based on the location of the associated inode for this data object. For example, the logical position can include the physical position of some offset in addition to the inode where this data object is stored. Fileset manager 214 sets the LCG field 302 to the current generation value for data object A. For example, if the last committed consistency snapshot had a value of 5, Fileset Manager 214 would set the LCG field 302 to 5. The context fields (306, 308) are set to either 0 or 1 to distinguish between the two contexts (the context being committed and the context being updated). Therefore, if a second context is needed, these two context fields 306, 308 will have opposite values. If only one context is needed, these two context fields 306, 308 will have the same value. Fileset manager 214 assumes that LCX field 306 is set to 1. The settings for the LUX field 308 are described below. The work of Flowchart 500 continues at continuation point A (518).

The continuation point A (518) continues at the continuation point A (602) in the flowchart 600. From continuation point A (602), work continues at 603.

Fileset manager 214 determines if the value of the LCG or LUG field in the buffer header for data object A matches the generation value of the transaction (603). With reference to FIGS. 2-3, the file set manager 214 determines whether the value of the LCG field 302 or the value of the LUG field 304 in the buffer header 300 matches the transaction generation value. The transaction generation value is set to the consistency generation based on when the transaction was created. Therefore, Fileset Manager 214 determines if this generation associated with a transaction is equal to the last committed generation or the last updated generation. If there is no match, work continues at 604. Otherwise, work continues at 616 (more described below).

Fileset Manager 214 makes a second copy of Data Object A from the first copy of Data Object A (604). With reference to FIG. 2, assuming that the first copy 250 of the data is the first copy of the data object A, the fileset manager 214 makes the first copy 250 of the data a different location in memory 218-data. Copy to the second copy 252-. The work of Flowchart 600 continues at 606.

Fileset manager 214 updates the second data pointer in the buffer header to point to a second copy of data object A (606). Referring to FIGS. 2-3, the file set manager 214 updates the data pointer 1 field 316 to point to a second copy of the data object A in memory 218. The work of Flowchart 600 continues at 608.

Fileset Manager 214 updates the LUX field in the buffer header to have the opposite value of the LCX field (608). Referring to FIGS. 2-3, the fileset manager 214 updates the LUX field 308 to have a value opposite to that of the LCX field 306 in the buffer header 300. As mentioned above, the value of LCX field 306 and LUX field 308 can be one of two values. When a dual context situation occurs (as in this case), the values of LCX field 306 and LUX field 308 are opposite to each other. The work of Flowchart 600 continues at 610.

Fileset manager 214 sets the generation value for the LUG field in the buffer header based on the generation value for the transaction (610). With reference to FIGS. 2-3, the fileset manager 214 updates the generation value for the LUG field 304 based on the generation value for the transaction (the description of the generation value for the transaction in the description of 603 above). reference). The work of Flowchart 600 continues at 614.

Fileset Manager 214 updates a second copy of Data Object A based on this transaction (614). With reference to FIGS. 2-3, assuming that the second copy 252 of the data is the second copy of the data object A, the fileset manager 214 is based on the pointer value in the data pointer 1 field 316. Update the second copy 252 of the data. The work of Flowchart 600 is completed along this path of Flowchart 600.

Returning to 603, if there is a match (yes), Fileset Manager 214 uses the first data pointer associated with the LUX field in the buffer header for data object A to data. Update the copy of object A (616). In this situation, there was a match at 603, since the generation for the transaction would match the LUG field 304. With reference to FIGS. 2-3, assuming that the first data pointer points to the first copy 250 of the data, the fileset manager 214 will base the data on the pointer value in the data pointer 0 field 314. Update copy 250 of 1. The work of Flowchart 600 is completed along this path of Flowchart 600.

Additional updates to the same or different data objects in the file system can continue to be made. Similarly, after a consistent snapshot commit is complete, Fileset Manager 214 adds additional consistent snapshots (based on regular intervals for committing to permanently remember the consistent snapshots). Can be committed.

As will be appreciated by those skilled in the art, aspects of the subject matter of the present invention may be embodied as systems, methods or computer programs. Therefore, aspects of the subject matter of the present invention are complete hardware embodiments, complete software embodiments (including firmware, resident software, microcode, etc.) or combinations of software and hardware embodiments. They may all be broadly referred to as "circuits", "modules" or "systems" herein. Further, an aspect of the subject matter of the present invention is embodied in a computer-readable medium having one or more computer-readable media (s) and having computer-readable program code embodied on it. It may take the form of a computer program.

Any combination of one or more computer-readable media (s) may be utilized. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example, electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or devices, or any suitable combination of those described above. However, it is not limited to them. More specific examples (limited list) of computer-readable storage media include: electrical connections with one or more wires, portable computer diskettes, hard disks, random access memory (random access) memory (RAM), read-only memory (read-only memory, ROM), erasable programmable read-only memory (erasable computer read-only memory, EPROM or flash memory), optical fiber, portable compact. Disk read-only memory (compact disc) Ready-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In the context of this document, a computer-readable storage medium can be any tangible medium that can include or store programs used by or in conjunction with instruction execution systems, devices or devices.

The computer-readable signal medium may include, for example, a propagated data signal in which the computer-readable program code is embodied, either in the baseband or as part of a carrier wave. Such propagated signals may take any of various forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A computer-readable signal medium is not a computer-readable storage medium, but any computer-readable medium capable of transmitting, propagating, or transporting a program used by or in conjunction with an instruction execution system, device or device. Just do it.

The program code embodied on a computer-readable medium includes, but is not limited to, wireless, wired, fiber optic cable, RF, etc., or any suitable combination of those described above. It may be transmitted using a different medium.

Computer program code for performing work for aspects of the subject of the invention is an object-oriented programming language such as Java (R), Smalltalk (R), C ++ or the like, as well as a "C" programming language or It may be written in any combination of one or more programming languages, including conventional procedural programming languages such as similar programming languages. The program code runs entirely or partly on the user's computer as a stand-alone software package, partly on the user's computer and partly on the remote computer, or completely remote. -It can be executed on a computer or a server. In the latter scenario, the remote computer is a local area network (LAN) or wide area network (wide area). It may be connected to the user's computer through any type of network, including network, WAN), or the connection may be made to an external computer (eg, through the Internet using an Internet service provider). ..

Aspects of the subject matter of the present invention are described with reference to the flow charts and / or block diagrams of the methods, devices (systems) and computer programs according to the embodiments of the subject matter of the present invention. It will be appreciated that each block of the flow chart and / or block diagram, and the combination of blocks in the flow chart and / or block diagram, can be implemented by computer program instructions. These computer program instructions may be provided to a general purpose computer, a dedicated computer, or the processor of another programmable data processing device to create a machine, whereby the instructions are computer or other programmable data processing. It runs through the processor of the device and creates a means to implement the function group / operation group specified in the block or block group of the flowchart and / or block diagram.

These computer program instructions may be stored in a computer-readable medium that can direct the computer, other programmable data processing device, or other device to function in a particular manner, thereby the computer. The instructions stored in the readable medium produce a product containing instructions that implement the function / operation specified in the block or group of blocks or blocks of the flowchart and / or block diagram.

Computer program instructions are loaded onto a computer, other programmable data processor or other device to perform a series of work steps on the computer, other programmable device or other device, and the computer implementation process. The instructions executed on a computer or other programmable device may produce a function group / operation group specified in a block or block group of a flowchart or a block diagram or both. Provide a group of processes.

FIG. 7 shows an example of a computer system. The computer system includes a processor unit 701 (which optionally includes a plurality of processors, a plurality of cores, a plurality of nodes, and / or implements a multi-thread or the like). The computer system includes memory 707. The memory 707 is a system memory (eg, cache, SRAM, DRAM, zero capacitor RAM, twin transistor RAM, eDRAM, EDO RAM, DDR. It may be one or more of RAM, EEPROM, NRAM, RRAM, SONOS, PRAM, etc.), or any one or more of the machine-readable media already described above that are feasible. There may be. Computer systems include bus 703 (eg, PCI, ISA, PCI-Express, HyperTransport (R), InfiniBand (R), NuBus, etc.), network interface 705 (eg, ATM interface, Ethernet (R) interface, frame). Also included are relay interfaces, SONET interfaces, wireless interfaces, etc.), and storage devices (s) 709 (eg, optical storage, magnetic storage, etc.). The computer system also includes a fileset manager 725 that provides multiple contexts for the data objects in the redirect on write file system. Any one of these functionality may be implemented, in part (or completely), in the form of hardware, on the processor unit 701, or both. For example, the functionality may be implemented in a coprocessor on a peripheral device or card, etc., with logic implemented in the processor unit 701 using an application-specific integrated circuit. In addition, the reality may contain fewer components, or additional components not shown in Figure 7 (eg, video cards, audio cards, additional network interfaces, peripherals). Devices, etc.) may be included. The processor unit 701, the storage device (s) 709 and the network interface 705 are coupled to the bus 703. Although shown to be coupled to bus 703, memory 707 may be coupled to processor unit 701.

Although embodiments have been described with reference to various implementations and uses, it will be appreciated that these embodiments are exemplary and that the scope of the subject matter of the present invention is not limited thereto. Many modifications, changes, additions and improvements are possible.

Multiple examples may be provided for components, operations or structures described herein as a single example. Finally, the boundaries between the various components, between the tasks and between the data stores are somewhat free to determine, and the particular task is shown in the context of a particular exemplary configuration. Other allocations of functionality are envisioned and may be included within the scope of the subject matter of the present invention. In general, structures and functionality presented as separate components in a configuration example may be implemented as combined structures or components. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other modifications, modifications, additions and improvements may be included within the scope of the subject matter of the present invention.

200 system 202 node A 204 node B 206 node N 208, 210 Client devices 212 network 214 Fileset Manager 216 Non-volatile machine-readable medium 218 memory 220 Buffer header A 222 Buffer header N 224 Consistency Snapshot A 226 Consistency Snapshot N 228 Current Consistency Snapshot 230, 232, 234 work First copy of 250 data Second copy of 252 data 254 Context in progress 256 Updating context