MoFS Client

Figure 3.2 shows that MoFS Client is composed of libfuse, MoFS Client Application, SSH Client, in user space, and VFS, FUSE kernel module, Ext3, in kernel space. VFS, FUSE kernel module, libfuse, and MoFS Client Application construct a user-level file system for easy deploy-ment. VFS, Ext3, and MoFS Client Application construct a local cache to use in disconnected operation. MoFS Client Application and SSH Client protect the transmission data securely with SSH protocol. The behavior of VFS, FUSE kernel module, Ext3, libfuse, and SSH Client is similar to their action in AshFS. MoFS Client Application is a client program to maintain file caching, network status, and client requests. MoFS Client Application is composed of File Op-eration Manager, Data Manager, Network Manager, Upload Manager, and Version Manager.

The relationship of these managers shows as Figure 3.2. The File Operation Manager (FOM) implements file system operations, like open, read, write, close, and so on. The Data Manager (DM) maintains local file cache and metadata information. The Network Manager (NM) mon-itors network status and executes network commands. The Upload Manager (UM) optimizes files in the upload queue. The Version Manager (VM) controls the version of the local file cache.

3.2.1 File Operation Manager (FOM)

In our design, the FOM implements file system operations, like open, read, write, close, and so on. The FOM is a implementation of the API which provide by FUSE library. When creating a new file or reading/writing a file, it will communicate with the Data Manager for getting file's information. When the request relates to network, get file's metadata from server for example, it pushes the request into upload queue of Upload Manager.

VFS

Figure 3.2: Architecture of MoFS Client.

3.2.2 Data Manager (DM)

The DM maintains local file cache and metadata information. For using less network pack-ages, we do not download all the files in server. When we list the server directory, we only get the stat structure of files in the server directory. In this method, we can download the files what we actually need. At the first time we open the file, the file start to download. Another mechanism for decreasing communication packages is writeback-on-close. We only upload the modified file to server when the file is closed.

3.2.3 Network Manager (NM)

The NM monitors network status and executes network commands. We divide the connec-tion status, like AshFS, into three states: Strong, Weak, and Disconnect. We define the three states by using ICMP packets as showing in Figure 3.3 When we execute any file operators, like open, we need to check the network status to know if we can send any commands to the file server. First, we send an ICMP packet and waiting for it's reply. If the reply packet returns

in 100ms, we define the network status in Strong State. Otherwise, we send an ICMP packet again. The second time for waiting the reply, we set the timeout as twice than the first ICMP packet. If the reply does not timeout, we define it in Weak State. Provided that the timeout still happens, does not reply in 200ms, we define the network status in Disconnect State.

Send the First

Figure 3.3: The Flow of Checking the Network States

3.2.4 Upload Manager (UM)

The UM optimizes files in the upload queue. We want to decrease the usage of communica-tion, so we design an upload optimizer, like AshFS. When using a file system, people may doing some redundant works, like creating a file and deleting the file in short period of time. The main action of the optimizer is to reduce the redundancy. The UM uploads the file to the server only at the Strong State, so the optimizer has different behaviors at different network status. At the Strong State, if there has no any other file operations, no download files or no fetch metadata, the UM upload files immediately. But at Weak State and Disconnect State, the files put into an upload queue waiting for the Strong State to come. At these two states, the UM monitors whether the file is removed by user. If user removes the file, the UM delete the entry of the file

in upload queue.

3.2.5 Version Manager (VM)

The VM controls the version of the local file cache. In AshFS, when a reintegration occurs, system resolves the staleness between server and client. At this situation, file may be have some conflicts. AshFS use the ``rename'' mechanism to solve conflict programs. The "rename"

mechanism changes old file to a new name with timestamp, and changes the latest file to the real name. It is confused at viewing the directory by using "rename" mechanism. The real files are overwhelmed by other renamed files. Version control is another choice to decrease this situation.

Using version control mechanism, we put the older version file into the repository. If we discover that the file in repository is the real file we need, we can revert the file from the repository by using version control mechanism. In version mechanism, we only save different part in old version. By using ``diff'' we decrease the disk usage comparing with rename mechanism in AshFS. However, version control mechanism may cause operation overhead at resolving content conflict.