Message based file system

File system components of a messaged based file system may perform different functions of the file system and may communicate through a file system-independent message interface to fulfill file I/O naming requests. A file system component may receive a message from another file system component and in response may perform a sub-function of the file system and then may send another message to a file system component to perform another function of the file system. File system components may each operate on separate devices or multiple file system components may execute on a single device. File system components may also communicate using messaging components that in turn may communicate with other messaging components according to the file system-independent message interface. A single messaging component may be configured to communicate with multiple file system components on a single device. Alternatively, each file system component may communicate through a single, paired messaging component.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to file systems in general and more particularly to distributed file systems.

2. Description of the Related Art

A file system is a method for storing and organizing files to make it easy to find and access the data stored in those files. Traditionally, file systems have been implemented using a single piece of software performing all functions of organizing and keeping track of files in the file system. Such file system software generally has to be capable of resolving naming issues, authenticating client users/applications, loading and storing data to physical storage devices, and any other task related to the file system. File system software is frequently included as part of an operating system to allow applications of the operation system to access data files. Hierarchical file systems allow applications to store and group data files in directories using a tree structure. Generally, file system software is implemented as a single, discrete, piece of software and the files managed by the file system software are typically stored on a single storage device, such as a hard-drive, frequently connected directly to the machine executing the file system software. The different operations of the file system software are typically implemented as different functions in the file system software. Communication between different functions of file system software is generally performed using direct function calls using file system specific parameters.

SUMMARY

A messaged based file system may be implemented using file system components, according to various embodiments. Different file system components may perform different functions or sub-functions of the message based file system, in some embodiment. For example, one file system component may perform a name resolution function, while another file system component may perform a security or authentication function, in one embodiment. The various file system components that make up a message based file system may communicate through a file system-independent message interface. For example, in one embodiment, a first file system component may receive a client application's file I/O request and may send a file system-independent message to a security file system component to authenticate the client application. The security file system component may authenticate that the client application may access the requested file and may, in some embodiments, send a response message through the file system-independent message interface to the first file system component indicating the successful authentication of the client application. After receiving the response from the security component, the first file system component may then send a message to another file system component to complete the client application's requested file I/O.

In one embodiment, a single main file system component may manage the fulfillment of the entire file I/O request by sending and receiving messages to various other file system components as needed. In other embodiments however, the various file system components may send messages regarding the requested file I/O to each other without requiring a single component to manage the process. For example, a first file system component may receive the file I/O request and send a file system-independent message to a naming file system component that in turn may send a message to a storage file system component and only send a response back to the first file system component after receiving the response from the storage file system component. Thus, file system components may function in a chain to fulfill a file I/O request, or one file system component may send messages to each file system component in turn, according to different embodiments. In other embodiments, a combination of these schemes may be used. In some embodiments, each file system component may execute on a separate device, while in other embodiments, multiple file system components may execute on a single device.

In certain embodiments, file system components may communicate using messaging components. In such embodiments, the messaging components may communicate with other messaging components according to a file system-independent message interface. Each messaging component may also communicate with a file system component. In one embodiment, a single messaging component may be configured to communicate with multiple file system components on a single device, while in other embodiments, each file system component may communicate through a separate messaging component, even if multiple file system components and multiple messaging components execute on a single device. A message based file system may implement any of various kinds of file systems and may use the same file system-independent message interface regardless of the specific underlying file system structure.

In some embodiments, file system components may be distributed on different computers or devices on a network and may communicate with each other over the network according to a file system-independent message interface. In one embodiment, a message based file system may utilize a file system-independent message interface and may thus avoid using programmatic interface, such as remote procedure calls (RPCs) and direct function calls. In one embodiment, the file system-independent message interface may use a non-programmatic interface or message format, such as including data representations of what would otherwise be code-based or programmatic system parameters.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1is a block diagram that illustrates a computer system implementing a message based file system, according to one embodiment. In such an embodiment, host computer100may implement a message based file system, such as file system130, that may include various file system components, such as naming component140and data access component160. In such an embodiment, naming component140may provide a name resolution function for file system130and data access component160may provide data loading and storing to and from physical storage220. For instance, application120may request data from a file on physical storage220by communicating to file system130. To fulfill application120's file I/O request, file system130may communicate with naming component140through a file system-independent message interface. The use of a file system-independent message interface allows file system130to communicate with different file system components, such as naming component140and data access component160, without using different message interface specific to each file system component. In one embodiment, a file system-independent message interface may be implemented through a separate, distinct, software module or library. When the file system-independent message interface is utilized through a separate software library, individual file system components may, in one embodiment, be developed separately from other file system components.

A message based file system may be implemented compatible with any of a number of current file systems including, but not limited to, Unix File System, DOS, Windows File System, and Network File System, according to various embodiments. A message based file system may be implemented, in one embodiment, by dividing up an existing file system standard and distributing various functions or operations compatible with the existing file system standard into different file system components of the message based file system. For instance, in one embodiment, a message based file system compatible with the Unix file system may include one file system component to implement the name resolution requirements of the Unix file system while including another file system component, possible executing on a separate computer or device, to perform client authentication and other security operations according to the Unix file system standards. Since, according to some embodiments, the different file system components may communicate through a file system-independent message interface, different file system components compatible with different existing file system standards may communicate and cooperate efficiently together in a message based file system.

Since, according to some embodiments, file system components communicate according to a file system-independent message interface, a message based system may easily include file system components compatible with multiple existing file system standards. For instance, in one embodiment, a message based file system may include file system components compatible with the Unix file system and also include file system components compatible with Network File System.

In some embodiments, as illustrated inFIG. 1, a message based file system, such as file system130, may also include one or more messaging components, such as messaging component(s)150. A messaging component may communicate with other messaging components using a file system-independent message interface and may also communicate with one or more file system components, according to various embodiments. For example, as illustrated inFIG. 1, file system130may send a message to messaging component150A including information regarding a file I/O request from application120. Messaging component150A may then forward part or all of the information from file system130to naming component140and may return a response from naming component140to file system130, according to one embodiment.

Additionally, if the name resolution function performed by naming component140was successful, file system130may then send a message to messaging component150B and messaging component150B may supply some or all of the information in that message to data access component160, and data access component160may then perform actual data loading or storing from or to physical storage220, according to certain embodiments. For instance, application120may issue a file read request to file system130. The actual mechanism used by application120to issue such a file I/O request may vary from embodiment to embodiment. For example, in one embodiment, application120may call a specific function from an API exposed by file system130. When making a file read request, application120may, in certain embodiments, reference a file name or path. File system130, may then send a message to naming component140, possibly using messaging component150A, in order to translate the file name or path specified by application120into a specific location on physical storage220where the data for that file resides, according to one embodiment.

According to some embodiments, file systems components of a message based file system communicate through a file system-independent message interface. In one embodiment, such a message interface may include different message definitions for different functions, while in other embodiments, a single message format may be used that includes information enabling any file system component to perform whatever function or sub-function required. For example a message format that includes all the relevant information regarding a requested file I/O and that also includes information indicating the current status of each step or function of the file I/O may be passed around among the various file system components.

For instance, in one such embodiment, a message sent by file system130may include the file name or path and a request for name resolution regarding physical storage220. Yet in other embodiments, such a message may also include information indicating the current status of name resolution, authentication, encryption, or data access functions of the file system, among other things. Thus rather than using file system specific parameters or messages, a message based file system may use a file system-independent message interface that may, in some embodiments, allow file system components of disparate file systems to communicate efficiently and effectively. Also, in some embodiments, the use of a file system-independent message interface may ease the process of including support for new or future file system functions or storage paradigms.

In one embodiment, file system130may not know that the requested file resides on physical storage220and naming component140may provide that information to file system130as part of this name resolution function. In other embodiments, file system130may include the entire file I/O request in the message sent to naming component, possibly through messaging component150A, and naming component may then translate the file name into a physical location where the data for that file resides and may then send a message to data access component160including the data location and also including the requested file I/O, according to one embodiment. Thus, in one embodiment; naming component140may provide name resolution information to file system130and file system130may then send a message to data access component160for actual data reading or writing. In another embodiment, though, naming component140may send the message to data access component160and not send a response to file system130until data access component160has read the requested data from the location specified by naming component140.

WhileFIG. 1illustrates, according to one embodiment, a message based file system using only two file system components, naming component140and data access component160, other embodiments may use more and different file systems components when implementing message based file system. In general, the number of file system components included in a message based file system may vary from embodiment to embodiments and in some embodiments, file system components may be dynamically added or removed from a message based file system without stopping or restarting the file system. Thus, host100may, in one embodiment not illustrated byFIG. 1, include only one messaging component150that both naming component140and data access component160may use to communicate with each other.

According to some embodiments, file system-independent messaging, as described herein, may facilitate the distribution of any file system. For example, in one embodiment, a messaging library that communicates according to a file system-independent message interface may be provided and may allow an existing file system to be compartmentalized for distribution on one or more devices and thus the functionality of the existing file system may be included in a message based file system. Alternatively, in another embodiment, an existing file system may be compartmentalized for distribution and file system-independent messaging capabilities may be included in each resulting file system component without using a separate message library. By communicating according to a file system-independent message interface, a message based file system may, in some embodiments, implement a file system including file system components from different vendors and may mix and match file system component from the different vendors if all the components are configured to component according to the same file system independent message interface.

File systems components may communicate with a messaging component using any of a number of different communication mechanisms, according to various embodiments. For example, in one embodiment, messaging component150may expose an API including one or more functions that naming component140may call to communicate with other file system components. In another embodiment, naming component140may use a shared memory feature of host100to communicate with messaging component150. In yet another embodiment, messaging component150may be linked into naming component140as a separate code module, while in other embodiments, messaging component150may be a separate dynamic library that naming component140loads during execution. Thus, there are many different ways for file system components to communicate with message components.

FIG. 2is a block diagram illustrating one embodiment of a message based file system including a client device and a server device. In such an embodiment, the message based file system is distributed across multiple devices communicating over network200. For example, client application220on client device240may want to read data from a file through client file system230. In one embodiment, client file system230may include naming component140and messaging component150C and together with file system250on server device210, which may include data access component160and messaging component150E, may implement a message based file system.

Thus, in response to client application220's file read request, client file system230may first use naming component140to resolve the requested file's name to a physical storage location, and may also communicate with data access component160of file system250on server device210to read the data from physical storage260, according to one embodiment. In one embodiment, client file system may use messaging component150C to communicate with naming component140and may also use messaging component150C to communicate with data access component160on server device210through messaging component150E. In another embodiment, client file system230may communicate directly with naming component140, but may use messaging component150C to communicate across network200to data access component160.

In certain embodiments, client file system230may represent a sort of master file system component for client device240and may manage the use of other file system components on the same device. Likewise, in such an embodiment, file system250may be a master file system component for server device210, managing other file system components on the same device. For example, client application220may issue a file read request to client file system230and file system230may communicate with naming component140for name resolution and may also use messaging component150C to retrieve the data from physical storage260on server device210. In one embodiment, messaging component150C on client device240may communicate with messaging component150E on server device210. In such an embodiment, messaging component150E on server device210may receive a message from message component150C and communicate with file system250and file system250may then interact directly with data access component160to read data from physical storage260. In another embodiment however, messaging component150E may, after receiving a message from messaging component150C interact directly with data access component160to read the requested data from physical storage260. Thus, according to different embodiments, each file system component may communicate directly with individual file system components on other devices or may communicate with a master file system component that will then interact with other file system components that each may perform a smaller sub-function for the master file system component.

Network200, as illustrated inFIG. 2, may comprise any of various network technologies according to various embodiments. Network200may be a local area network, wide area network, intranet network, Internet network, peer-to-peer network, or many other types of network. Network200may be designed to be continuously available (although network outages may occur), or may be intermittent (e.g. a modem connection made between a computer system in a user's home and a computer system in a user's workplace). Network200may utilize any of a number of different physical networking technologies including, but not limited to, Fiber Channel, Ethernet, Fast-Ethernet, Gigabit-Ethernet, Myrinet, Infiniband, VAX CI, or ServerNet, or others. Network200may be configured according to a number of different network topologies including, but not limited to, star, token-ring, token-bus, scatternet, dual-ring, mesh, etc.

Network200may also be configured to utilize a combination of different networking technologies and/or topologies. Additionally, Network200may comprise shared storage or shared memory for communicating between different computer systems or between processes within the same computer system, according to some embodiments. In some embodiments, Network200may be the interconnect network for any of various distributed shared storage environments, including, but not limited to, network file system (NFS), common Internet file system (CIFS), storage area network (SAN), network attached storage (NAS), storage-network aggregation, multi-site block storage, object-based storage devices (OBSD), or other asymmetric, out-of-band, or shared storage models.

When a message based file system is distributed across multiple devices, as illustrated inFIG. 2, various file systems components may reside on different devices. For example, naming component150C may reside on client device200as part of client file system230and data access component160may reside on server device210, according to one embodiment. The specific file system components and devices illustrated inFIG. 2are intended only as a single example to simplify explanation. Message based file system may include many more devices and file system components than illustrated byFIG. 2, according to various embodiments. In some embodiments, a file system component on one device, such as naming component140on client device240may communicate with a file system component on another device such as data access component160on server device210. In one embodiment, naming component140may communicate directly with data access component160, while in other embodiments, naming component140may communicate with data access component160through messaging components, such as messaging components150. When using messaging components, naming component140may interact with messaging component150C that may in turn communicate with messaging component150E, according to one embodiment.

Thus, the functions performed by naming component140and data access component160which were performed on a single device in the embodiment illustrated inFIG. 1may be distributed across two devices, namely client device240and server device210in the embodiment illustrated byFIG. 2. In other embodiments, additional file system functions, such as encryption/decryption, authentication, etc. may be performed by additional file system components execution on additional devices.

The exact mechanism used within a message based file system for communication between messaging components or between file system components may vary from embodiment to embodiment and may also vary depending upon the underlying nature of network200. For example, in one embodiment, network200may be the Internet and messaging component150C may send a TCP/IP message across network200to messaging component150E. In another embodiment, messaging component150C may utilize a remote procedure call to communicate with messaging component150E.

In certain embodiments, additional file system components may be dynamically added to a message based file system or existing file system components may be dynamically removed from the file system during execution without stopping and restarted the message based file system. In one embodiment, the exact number and location of the various file system components may not be determined until execution. The methods and mechanisms used by file system components to determine other file system components available in the message based file system may vary from embodiment to embodiment. For example, in one embodiment, the file system components may use a peer-2-peer communication mechanism to discover each other. In another embodiment a single mail file systems component may maintain information about the various file system components available in the message based file system and may provide that information to other file system components. The exact nature of the various mechanisms that may be employed to discover or address the various file system components of a message based file system are well understood in the field of network communication and are not discussed herein.

FIG. 3is a block diagram illustrating a message based file system including multiple distributed file system components, according to one embodiment. In some embodiments, file system components executing on one device may communicate with file system components on other device in order to perform their respective functions of a message based file system. For example, even through client file system230on client device240may include naming component140and data access component160, the actual naming and data access function may be performed by file system components executing on other devices. For instance, in response to a file write request from client application220, client file system230may request naming resolution from naming component140. In turn, naming component may communicate with metadata server300to load the metadata for the requested file.

Thus, in some embodiments, file system components executing on one device, such as naming component140, may utilize file system components executing on other devices, such as metadata server300, executing on other devices. In some embodiments, metadata server300may also communicate with yet other file system components on yet other devices regarding a file I/O request. For example, metadata server300may also communicate with metadata server310, or perhaps another metadata server, through messaging components, such as messaging components150G and150H, to ensure data coherency across multiple metadata servers.

Similarly, data access component160may communicate with messaging component1501and/or messaging component150J for access to data on physical storage320or330respectfully. In one embodiment, physical storage330and physical storage320may be mirrored systems and messaging components150I and150J may communicate to ensure that changes to one storage system, such as physical storage320, are reflected or copied to the other, such as physical storage330.

In one embodiment, as illustrated byFIG. 3, client file system230may include a single messaging component150F that performs all the communication necessary between various file system components. In other embodiments, client file system230may include a separate messaging component for each file system component and may even include a separate messaging component to communicate with file system components on other devices. Thus in one embodiment naming component140may use messaging component150F to communicate with both data access component160and metadata server300, while in another embodiment, naming component140may use messaging component150F only to communicate data access component160and my use a different messaging component not illustrated inFIG. 3, to communicate with metadata server300.

FIG. 4is a block diagram illustrating one embodiment of a message based file system including duplication of file system components on multiple devices. As illustrated inFIG. 4, a message based file system may include duplicate file system components on multiple devices. For example, a message based file system may be implement across host device100, and remote device400, according to one embodiment. In such an embodiment, host device100may include various file system components, such as security component410, naming component140, and data access component160. Additionally, the message based file system illustrated inFIG. 4may also include data access component160on remote device400.

Both instances of data access component160may perform the same data access functions to the same physical storage system, such as physical storage310, according to certain embodiments. In other embodiments, each instance of data access component160may provide data access functionality to two separate, but mirrored storage systems, thus providing naming component140an option of which instance of data access component160to when requesting data access functionality, according to some embodiments. For example, in one embodiment, naming component140could use the remote instance of data access component160in order to free up host device100for other processes. In other embodiments, the two instances of data access component160may be configured to communicate with each other for coherency or other data replication purposes. In general, file system components may be duplicated across multiple devices for various reasons according to different embodiments.

As described above, in some embodiments, the file system components on both host device100, and remote device400may also include various messaging components not shown inFIG. 4.

FIG. 5is a flowchart illustrating one embodiment of a method for implementing a message based file system. A file system component, such as naming component140, of a message based file system may receive a file system-independent message including I/O information corresponding to a file I/O request of a client application as illustrated by block500, according to one embodiment. For example, application120may desire to read a file and may make a corresponding file I/O request to message based file system130. File system130may in turn send a message, according to a file system-independent message interface, to naming component140including information regarding the file I/O request such a the file name and path, and what sections of the file to read. A file component may also perform a sub-function of the distributed file system as illustrated by block520, in one embodiment. Thus, after receiving a message regarding application120's file I/O request, naming component140may perform a sub-function, such as resolving the file name and path to a physical storage location where data for that file may be found.

A message based file system may, in some embodiments, be distributed even if all the file system components of the file system execute on a single device. For example, the file system may be distributed because different components perform different functions of the file system and file system-independent messages may be used to communicate between them. Additionally, in one embodiment, a file system component may send a file system-independent message to another file system component configured to perform another sub-function, as illustrated by block540. For instance, after resolving the requested filename and offset to physical storage locations, naming component140may send a message to data access component160and data access component160may perform the actual reading of the data from the physical locations provided by naming component140. As described above, file system components may communicate with each other directly, or may use one or more messaging components configured to communicate with each other, according to various embodiments. Additionally, file system components may reside on the same physical device or may execute on separate devices, in different embodiments.

FIG. 6is a flowchart illustrating one embodiment of a method for implementing a message based file system. In some embodiments, multiple file system components may be configured to perform the same sub-function of the message based file system, such as a file system that include mirrored data or multiple metadata servers each configured to provide metadata for the same set of files. In such an embodiment, a file system component may send a file system-independent message to a plurality of file system components as illustrated by block600and may then receive a response from one of the file system components indicating completion of a sub-function of the distributed file system, as illustrated by block620. For example, naming component140may send a file system-independent message to data access component160through messaging component150F, as illustrated inFIG. 3, and data access component160may send a file system-independent message to both messaging components150I and150J to read data from mirrored physical storage320and330, according to one embodiment. Thus, since the same data may be read from either physical storage320or physical storage330, and since one of the physical storage systems may already be in use, or may be slower than the other, data access component160may send a file system-independent message requesting the data to both of them, in one embodiment.

Additionally in such an embodiment, data access component160may receive a response including the requested data from one of the physical storage systems before receiving a response from the other. After receiving a response from one of the file system components, the first file system component may send a response including completion of the sub-function of the distributed file system, as illustrated by block640. Thus, data access component160, after receiving a response from physical storage320, may send a response back to naming component140including the requested data or other information indicating the completion of the data read, in one embodiment. The information indicating the completion of a sub-function of the distributed file system may indicate the success or failure of the sub-function, according to various embodiments. After sending a response indicating the completion of the sub-function, the file system component may discard any responses from other file system components as illustrated by block660. For example, data access component160may, after receiving a response from messaging component150I including data from physical storage320, ignore or discard a response from messaging component150J.

FIG. 7is a flowchart illustrating one embodiment of a method for including dynamically added file systems components to a message based file system. In some embodiments, file system components may be dynamically added to a message based file system and existing file system components may be configured to recognize the new, dynamically added file systems components and send messages to them. Thus, a file system component may receive information indicating a new file system component dynamically added to the distributed file system, as illustrated by block700. For example, in one embodiment, naming component140may only know about one metadata server, such as metadata server300illustrated inFIG. 3and may receive information indicating a new metadata server available in the message based file system, such as metadata server310. Additionally, a file system component may also receive a file system-independent message including file I/O information corresponding to a file I/O request as illustrated by bock720. A file system component may then send a message to the new file system component as illustrated by block740, according to certain embodiments. In such an embodiment, naming component140may, after receiving information that indicating metadata server310is available in the distributed file system, send messages to metadata server310through the file system-independent message interface to get metadata for files of the file system.

Since, according to some embodiments, the various file systems components of a message based file system may communicate according to a file system-independent message interface, a file system component may successfully communicate with a newly added file system component using the same file system-independent message interface. Thus, in various embodiments, existing file system components may not need to be modified to work with newly added file system components because all of the file system components, both new and existing, may communicate through the file system-independent message interface. Thus, a message based file systems, in some embodiments, may include various “pluggable” file system components, able to be dynamically included in the message based file system.

The exact manner in which a file system component, such as naming component140may receive information indicating a new file system component may vary from embodiment to embodiment. For example, in one embodiment, a new, dynamically added file system component, such as metadata server310, may announce its presence in the message based file system by broadcasting a message to all other file system components. Alternatively, in another embodiment, metadata server310may register-itself with a file system component configured to maintain information on all active file system components of the file system and that registry component may be configured to inform other file system components regarding the availability of metadata server310. In one embodiment, naming component140may be configured to periodically query such a registry component to determine if any file system components have been added to the file system.

FIG. 8is a flowchart illustrating one embodiment of a method for dynamically removing a file system component from a message based file system. Message based file systems may be implemented such that file system components may be dynamically removed from the file system, in some embodiments. File system components may be removed for various reasons, according to different embodiments. For example, in one embodiment, a file system component responsible for physical storage may be configured to remove itself periodically for backup purposes or for data integrity checks. In another embodiment, a file system component that can no longer be communicated with, perhaps due to a network failure, may be removed from the file system. Thus, a file system component may receive information regarding a file system component removed from the distributed file system, as illustrated by block800. In one embodiment, for example, a file system component may keep track of the various other file system components and may, after receiving information that one of the file system components is no longer available in the message based file system, either delete the remove file system component from its list, or may mark the file system component as unavailable, according to different embodiments.

After receiving information regarding a removed file system component, the file system component may also receive a file system independent message including file I/O information corresponding to a file I/O request, as illustrated by block820. Additionally the file system component may send a file system-independent message to one or more file system components, but may not send one to the removed file system component, as illustrated by block840. For example, in one embodiment, naming component140may receive information indicating that metadata server310is no longer performing metadata services in the message based file system. In such an embodiment, naming component140may then not send messages requesting metadata to metadata server310.

In certain embodiments, a file system component may be temporarily removed from the message based file system and may be added to the message based file system again at a later time. A file system component may be removed from a message based file system without removing the software from the device on which it is executing and without physically removing the device from the network, according to some embodiments. In such an embodiment, a file system component may simply be unavailable and may be made available by adding to back into the message based file system. A file system component may be temporarily removed from a message based file system for a number of reasons, such as bandwidth limitations, network connectivity failures, automatic software maintenance, or for upgrading the file system component, according to different embodiments.

As with the dynamic addition of file system components, described above regardingFIG. 7, the use of a file system-independent message interface may, in some embodiments, make the dynamic removal of file system components easy and efficient. For example, using a file system-independent message interface may allow file system component software to be upgraded without shutting down the entire message based file system, in some embodiments. For example, a new version of a file system component may first be added to the message based file system and the older version may then be removed from the message based file system, in some embodiments, both the addition and removal may be completely performed through the file system-independent message interface.

The exact manner in which a file system component receives information indicating that another file system component has been removed from the message based file-system may vary from embodiment to embodiment. As with the dynamic addition of file system components described above regardingFIG. 7, the dynamic removal of file system components may implement through various communication mechanisms. For example, in one embodiment, a file system component may voluntarily remove itself by broadcasting information indicating that it will no longer be performing any sub-functions of the message based file system. In another embodiment, a registry of active file system components may by maintained by a registry component, the dynamic removal of a file system component may be recorded in such a registry and other file system components may be configured to periodically query the registry component to learn about any file system components no longer performing their respective sub-functions in the distributed file system.

FIG. 9illustrates a computing system capable of implementing a message based file system as described herein and according to various embodiments. Computer system900may be any of various types of devices, including, but not limited to, a personal computer system, desktop computer, laptop or notebook computer, mainframe computer system, handheld computer, workstation, network computer, a consumer device, or any type of networkable peripheral device such as storage devices, switches, modems, routers, etc, or in general any type of networkable computing device. Computer system900may include at least one processor930. Processor930may couple across interconnect940to memory910.

Memory910is representative of various types of possible memory media, also referred to as “computer accessible media.” Hard disk storage, floppy disk storage, removable disk storage, flash memory and random access memory (RAM) are examples of memory media. The terms “memory” and “memory medium” may include an installation medium, e.g., a CD-ROM or floppy disk, a computer system memory such as DRAM, SRAM, EDO RAM, SDRAM, DDR SDRAM, Rambus RAM, etc., or a non-volatile memory such as a magnetic media, e.g., a hard drive or optical storage. The memory medium may include other types of memory as well, or combinations thereof.

In some embodiments, memory910may include program instructions configured to implement a message based file system, as described herein. In certain embodiments memory910may include program instructions configured to implement a file system component, such as file system component960. In such embodiments, file system component120may be configured to perform a sub function of a distributed file system as described herein. In other embodiments, memory910may include program instructions configured to implement a messaging component, such as messaging component150. In such embodiments, messaging component150may be configured to send and receive messages in a file system-independent message format with other messaging component and to communicate with file system components, as described herein.

In one embodiment, computer system900may be configured to communicate across network200through network interface950. In some embodiments, file system component960or messaging component150may be configured to communicate through network interface950to send and receive messaging in a file system-independent message format with other file system components or other messaging components, as described herein.

Although the embodiments above have been described in detail, numerous variations and modifications will become apparent once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.