Abstract:
Use and generation of an identifier. An indication of a value to be used to generate system-unique identifiers is received. The indication and an associated count value are stored in a metadata server interconnected with one or more remote metadata servers. A modified value to be used to generate system-unique identifiers generated based, at least in part, on the indication and the associated count value is transmitted to a remote metadata server.

Description:
TECHNICAL FIELD 
     Embodiments of the invention relate to file system management. More particurly, embodiments of the invention relate to techniques for use of a file management system having distributed metadata servers that may be used, for example, in a system that may support video editing, video archiving and/or video distribution. 
     BACKGROUND 
     In general, a file system is a program (or set of programs) that provides a set of functions related to the storage and retrieval of data. The data may be stored, for example, on a non-volatile storage device (e.g., hard disk) or volatile storage device (e.g., random access memory). Typically, there is a set of data (e.g., file name, access permissions) associated with a file that is referred to as “file metadata.” This file metadata may be accessed during the process of accessing a file. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements. 
         FIG. 1  is a block diagram of one embodiment of a system that may utilize a file system with distributed metadata servers. 
         FIG. 2  is a block diagram of one embodiment of an electronic system. 
         FIG. 3  is a conceptual illustration of Unique Shared Incrementing Values (USIVs) for use with three metadata servers. 
         FIG. 4  is a conceptual illustration of a local USIV, bucket value and threshold value that may be stored in a metadata server. 
     
    
    
     DETAILED DESCRIPTION 
     In the following description, numerous specific details are set forth. However, embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description. 
     System Overview 
       FIG. 1  is a block diagram of one embodiment of a system that may utilize a file system with distributed metadata servers. In one embodiment, the various components of the system of  FIG. 1  are interconnected using standard interconnection technologies (e.g., Ethernet, Gigabit Ethernet). For example, in one embodiment, switching fabric  150  may be a Gigabit Ethernet (or 10 Gigabit Ethernet) interconnection architecture to allow the various components of system  100  to communicate with each other. 
     In one embodiment, multiple client devices (e.g.,  130 ,  132 , . . .  138 ) may be interconnected via switching fabric  150 . Client devices may allow users to access and/or otherwise utilize data available through system  100 . In one embodiment, the client devices are computer systems having sufficient storage and input/output capability to allow users to manipulate data stored in various servers. For example, in a multimedia system, the client devices may allow users to access stored multimedia files as well as edit or otherwise utilize the multimedia files. 
     In one embodiment, the system of  FIG. 1  may include any number of metadata servers, each of which may store metadata for files that are stored in the system. In one embodiment, a metadata server may be responsible for managing the file system and may be the primary point of contact for client devices. In one embodiment, each client device may include file system driver (FSD) software that may present a standard file system interface, for accessing files the system. 
     In one embodiment, the various electronic systems of  FIG. 1  (e.g., data servers, metadata servers, clients) as an electronic system such as, for example, the electronic system of  FIG. 2 . The electronic system illustrated in  FIG. 2  is intended to represent a range of electronic systems, for example, computer systems, network access devices, etc. Alternative systems, whether electronic or non-electronic, can include more, fewer and/or different components. 
     Electronic system  200  includes bus  201  or other communication device to communicate information, and processor  202  coupled to bus  201  to process information. While electronic system  200  is illustrated with a single processor, electronic system  200  can include multiple processors and/or co-processors. Electronic system  200  further includes random access memory (RAM) or other dynamic storage device  204  (referred to as memory), coupled to bus  201  to store information and instructions to be executed by processor  202 . Memory  204  also can be used to store temporary variables or other intermediate information during execution of instructions by processor  202 . 
     Electronic system  200  also includes read only memory (ROM) and/or other static storage device  206  coupled to bus  201  to store static information and instructions for processor  202 . Data storage device  207  is coupled to bus  201  to store information and instructions. Data storage device  207  such as a magnetic disk or optical disc and corresponding drive can be coupled to electronic system  200 . 
     Electronic system  200  can also be coupled via bus  201  to display device  221 , such as a cathode ray tube (CRT) or liquid crystal display (LCD), to display information to a user. Alphanumeric input device  222 , including alphanumeric and other keys, is typically coupled to bus  201  to communicate information and command selections to processor  202 . Another type of user input device is cursor control  223 , such as a mouse, a trackball, or cursor direction keys to communicate direction information and command selections to processor  202  and to control cursor movement on display  221 . Electronic system  200  further includes network interface  230  to provide access to a network, such as a local area network. 
     Instructions are provided to memory from a storage device, such as magnetic disk, a read-only memory (ROM) integrated circuit, CD-ROM, DVD, via a remote connection (e.g., over a network via network interface  230 ) that is either wired or wireless providing access to one or more electronically-accessible media, etc. In alternative embodiments, hard-wired circuitry can be used in place of or in combination with software instructions. Thus, execution of sequences of instructions is not limited to any specific combination of hardware circuitry and software instructions. 
     An electronically accessible medium includes any mechanism that provides (i.e., stores and/or transmits) content (e.g., computer executable instructions) in a form readable by an electronic device (e.g., a computer, a personal digital assistant, a cellular telephone). For example, a machine-accessible medium includes read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals); etc. 
     Unique Shared Incrementing Values As File Identifiers 
     Distributed file systems, such as those described herein, require the ability to generate unique identifiers within the file system. These identifiers may be used, for example, to identify pieces of file data or to generate unique file handles. As described in greater detail below, use of a Unique Shared Incrementing Value (USIV) may be used as identifiers within a system. A USIV is a file system unique number used as a identifier for specific file system objects. 
     In one embodiment, the mechanism to generate and manage USIV requires the token mechanism described above. However, different communication mechanism that can insure a reliable and ordered sequencing could be used as a transport mechanism for the USIV management. 
     In one embodiment, a USIV is initiated as a small integer. A few small values (e.g., 0, 1, 2) may be reserved for special uses. In one embodiment, the value of the USIV may be transmitted as part of (or in association with) the token described above. In one embodiment, the USIV may be received by a metadata server, which may establish a “bucket” of local USIVs that may be used by the metadata server. The metadata server may then increment the USIV transmitted with the token by the number of values in the bucket. This allows the next metadata server to use non-overlapping USIVs. 
       FIG. 3  is a conceptual illustration of USIVs for use with three metadata servers. In the example of  FIG. 3  three metadata servers are illustrated; however, any number of metadata servers may be supported. Also, the bucket values and threshold values for the different metadata servers may be consistent across one or more metadata servers or metadata servers may have different bucket values and threshold values. 
     In one embodiment, upon system initialization a first metadata server (e.g., metadata server  340 ) may receive or generate an initial USIV. The USIV may be stored by metadata server  340  in a register or other storage mechanism  346 . Metadata server  340  may also store bucket value  342  that corresponds to a number of USIVs that metadata server may reserve for local use. In one embodiment, metadata server  340  may also store threshold value  348  that may be used to determine when metadata server  340  should obtain a new USIV and corresponding bucket. 
     In one embodiment, after storing USIV  346 , metadata server  340  may send new USIV  350  to metadata server  320 . In one embodiment, USIV  350  equals USIV  346  plus bucket value  342  plus one. For example, if USIV  346  is 50 and bucket value  342  is 1000, USIV  350  may be 1051, which is the next available USIV that may be used by metadata server  320 . 
     Metadata server  320  may repeat the process performed by metadata server  340 . That is, metadata server  320  may store USIV  350  as local USIV  324  and may store bucket value  322  and threshold value  328 . Metadata server  320  may then generate new USIV  330 , which may be USIV  324  plus bucket value  322  plus one. New USIV  350  may be transmitted to metadata server  360 . 
     Metadata server  360  may repeat the process performed by metadata server  320 . That is, metadata server  360  may store USIV  330  as local USIV  364  and may store bucket value  362  and threshold value  368 . Metadata server  360  may then generate new USIV  370 , which may be USIV  364  plus bucket value  362  plus one. New USIV  360  may be transmitted to metadata server  340 . 
     In one embodiment, once each metadata server has a local USIV bucket and a threshold value, the metadata server may update the local USIV as necessary and not necessarily each time a new USIV is received, for example, in association with a token. In one embodiment, a metadata server may only acquire a new USIV when the threshold value indicates that a new USIV should be acquired. This may be accomplished, for example, the threshold value may, indicate a level below which the bucket value should not drop thus indicating that a new USIV and bucket value should be acquired, or the threshold value may indicate a USIV through which the local USIV should not pass thus indicating that a new USIV and bucket value should be acquired. 
       FIG. 4  is a conceptual illustration of a local USIV, bucket value and threshold value that may be stored in a metadata server.  FIG. 4  illustrates example values for the local USIV (e.g., 2000), the bucket value (e.g., 1000) and the threshold value (e.g., 250). When the metadata server requires a USIV, for example, to create a new file, the local USIV (2000) may be used for the file and the local USIV may be incremented (2001). In response to the USIV being incremented the bucket value may be decremented (e.g., 1000 to 999). This process may continue for each use of a local USIV. 
     In one embodiment, when the bucket value is equal to or less than the threshold value, the metadata server may be triggered to acquire a new USIV the next time that the token is received. The new USIV may be acquired as described above with respect to  FIG. 3 . The metadata server may function using the new USIV in the manner described above. Thus, each metadata server may reserve a local allotment of USIVs that may be used by the metadata server without central control over identifiers to be used in a system with distributed metadata servers. 
     Conclusion 
     Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment. 
     In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.