Synopsis

This thesis has been organized in the following way. After making a brief introduction in

the Chapter 1, some related works will be showed in Chapter 2. Then we are going to interpret some important design issues in Chapter 3. Chapter 4 layouts AshFS’s system architecture and discusses our implementations. Several experiment results will be showed in Chapter 5, and finally, we will give our conclusions and outline the future work in Chapter 6.

Chapter 2 Related Work

File sharing is a common service as Internet became popular. People used client-side applications supporting interactive protocols like File Transfer Protocol (FTP) to download files from the server initially [18]. Such applications need their own network supporting code to make use of the remote server’s file resources [1]. However, what people really need is a file system that offers transparent accesses to remote files. From the application’s view, these files are indistinguishable from local files. Therefore many network filesystem were developed, and we are going to look these previous works here.

2.1 NFS

Network File System (NFS) is a network file system protocol originally jointly developed by Sun Microsystems and IBM in 1984. It is the first widely-deployed transparent file system [6]. NFS is almost the most common way to share files between UNIX-like servers since its simplicity and efficiency. The latest version of NFS is Version 4, but most sites currently implement Version 3(NFSv3). Because of its wide deployment and support (both by operating systems and by applications), features offered by NFSv3 can be considered a golden standard to which other network file systems can be compared.

NFS clients make no assumptions about server state and any caching of data is unofficial [1]. No server state means that the client is not aware of the server state. If the server crushes, the client can only wait until the server recovers, and file system operations will be blocked for a long time. Also NFS uses the minimal caching design. Although it means that there are few data consistency problems because almost every operation will see

the freshest result, it causes a long delay when the client is not in a low latency and high bandwidth network environment, because many messages of file system operations need to transfer over the network. Since NFS is originally designed for sharing files over a fast and reliable network[24], no server state and minimal caching make it a relatively easy implementation, excellent performance and easy error recover network file system. However, it is not suitable for the mobile networks.

Furthermore, NFS server uses IP address and subnet mask to identify its clients and limit the authority [9]. It is fine for sharing files over LAN because the range of IP is clear, and many clients have its own invariable IP addresses. Nevertheless, it’s not that condition for the mobile clients. It is hard to know where the client would go, so the scope of IP address cannot be definitely limited.

2.2 SAMBA

Samba is an open source software suite which makes UNIX and MS Windows can share files and print services with each other [14-15]. It is also a free software suite and was developed by many kinds of organizations since 1992. All manner of SMB/CIFS (Server Message Block/Common Internet File System) clients, including the numerous versions of Microsoft Windows operating systems, can use services provided by Samba. Current stable version of Samba is Version 3 (samba 3), and it’s also our comparison standard.

Samba identifies a user and limits its authority by using login name and password or some other more complex ways. Because of its cross-platform characteristic and safer authentication method, Samba is suitable for sharing files over the network. Although many authentication methods and options make Samba a secure and elastic network file system, theses options also let deployment cost higher. Problem-shooting also becomes more difficult because sometimes it’s not easy to find out the problem is on the client, the server, or just the

network environment.

Samba supports virtual memory cache, and can cache recently-used directories contents.

But the cache is not persistent, and it doesn’t cache whole-file contents, hence it doesn’t support disconnected operations. Samba is usually used for sharing files between Linux and Windows machines over LAN nowadays since its original design purpose and the not fully-functional cache. Accessing files on a Samba server over Internet may not be a good idea, because it could cause a long delay.

2.3 Coda

Coda is a file system for a large-scale distributed computing environment composed of Unix workstations [4]. It has been developed at CMU since 1987 by the systems group of M.

Satyanarayanan in the SCS department. Coda is still under development, and its current stable version is 6.9, though the focus has shifted from research to creating a robust product for commercial use.

The Coda file system started as an advancement of AFS and it introduced several new key features: disconnected operation, resolution of diverging replicas with bandwidth adaptation, and server replication. Each Coda client runs a process called Venus as the cache manager; Venus uses the local disk as a file cache and caches files and directories in their entirety. Once a file is cached, file system operations of this file will be redirected to the local file system without contacting to the server (if the cached file is fresh). When the server is out of reach, the client can still operate this file system and use the cached files, and Coda will switch to disconnected mode. In disconnected mode the updates are immediately applied to the local cached files and also logged. After the connection recovers, the log will be propagated to the server and will be replayed on the server. Before replaying the log, Coda examines if there is any confliction between the client and the server. If there are conflictions,

Coda will try to resolve these conflictions automatically (called “Conflict Resolution”). In case of server failure, server replication allows each volume (the storage unit in Coda) to have read-write replicas at more than one server. The set of replicas for a volume is its “volume storage group” (VSG). The subset of a VSG which permit a client can access is called

“Accessible VSG” (AVSG) [25].

Besides disconnected mode, Coda has other two operation modes: strongly connected and weakly connected. During strongly connected mode, Coda will prefetch some files for future use (called “Hoarding”). It makes users can use more files when disconnect from the server. The remote servers can be replicated for higher performance and fault tolerance, i.e.

Coda stores copies of a file at multiple servers. Even if some of servers are partitioned from the network, user can still fetch files from other servers. Because mechanisms listed above, Coda can achieve high availability.

However, Coda was originally designed for large-scale distributed computing environments, and it has strict maintenance in authentication and file consistency. Therefore it will sacrifice some performance and consume more network resources. In order to manage disconnected operation and synchronize data between multiple servers, Coda extents the RPC protocol to RPC2. But RPC2 is different from RPC of NFS and NetBIOS of Samba; it’s not a standardized protocol. In addition, Coda’s deployment is marginal outside the academic community [3], and causes its deployment and establishment costs are much higher than other file systems.

2.4 SSHFS

Sshfs is an abbreviation of secure shell filesystem, it allows users mounting an SSH server as a part of local file system [16-17]. It is a file system client based on SSH file transfer protocol (SFTP) and FUSE, a user-space filesystem framework. Sshfs can be running on

many OSs with a FUSE implementation such as Linux, Mac OS X and FreeBSD.

Since most Linux servers already support SSH and SFTP protocols, sshfs’ deployment is not difficult. There is nothing to do on the server side and on the client side mounting the file system is as easy as logging into a server with an SSH application. Sshfs uses multithread programming technique, i.e. more than one request can be on its way to the server. In addition, it caches directory contents temporarily for faster responses. However, this cache isn’t persistent and sshfs needs a consistent connection to the server. Once the connection between the client and the server is lost, it cannot handle this situation automatically, and manually remount is needed. In other words, Sshfs doesn’t support disconnected operation. For a mobile user, it is painful to deal with this connection problem by himself/herself.

2.5 RSC Filesystem for Symbian OS

Four Finland researchers have developed a framework called Remote Storage Client (RSC) framework for accessing remote file systems with Symbian OS phones [3]. RSC was inspired and informed by Coda, many design aspects are similar to Coda, but it adapted some of aspects to make it faster and more efficient. It supports disconnected operation with whole-file caching and immediate file access. While whole-file caching is a natural consequence of the requirement to support disconnected operation, immediate file access makes it more suitable for multimedia applications. Because these applications sometimes only require quick access to a portion of data, without any intention to consume the whole file.

Downloading the whole-file causes needless long delay.

Two protocol plug-in modules for RSC have been implemented: WebDAV and FTP.

WebDAV is an HTTP extension which allows users to collaboratively edit and manage files on remote web servers. They tried to use standardized protocols and preferably not require server-side changes. In this framework, the server is a standard WebDAV or FTP server, the

whole procedure is conducted by the client.

Immediate file access with block-level caching reduces the delay when opening a file, and sometimes makes file access more efficient. But this design is for multimedia files only.

When considering accessing normal files, RSC filesystem still needs to fetch the whole contents. Furthermore, RSC uploads the cached file in its entirety to the server for updating.

This is somewhat wastes the network resources if only a little part of the file was modified.

2.6 MAFS

MAFS is a file system for mobile clients and is tailored for wireless networks by incorporating automatic adaptation to the available bandwidth [5]. Rather than specifying a threshold for switching between synchronous and asynchronous writeback modes, it uses asynchronous writeback at all bandwidth level. But delaying writes at high bandwidth sometimes causes severe inconsistency problems, so MAFS incorporates a new invalidation-based update propagation algorithm, SIRP, to ensure that file modifications are propagated to the clients who need them in time. In addition, it uses RPC priorities to reduce interference between read and write traffic at low bandwidth, and reduce a client’s contention for wireless bandwidth. In a word, MAFS reacts to bandwidth variations in a file-grained manner and permits a degree of consistency.

MAFS also supports disconnected operation with whole-file caching. Although MAFS uses several ways to eliminate the fundamental problem of contention for insufficient bandwidth, it doesn’t try to reduce the client-server network traffic for file transferring, which could be the most bandwidth-consuming operation. In addition, MAFS doesn’t resolve conflicts automatically, but we think it is necessary for better consistency.

2.7 Summary

Now we list a table to describe our design goals and make a comparison of our related works. And we explain some terminologies listed in the table here.

z Mobile authentication: The target filesystem can recognize and authenticate a mobile user.

z Data encryption: All transferred data are encrypted for the security concerns.

z Differential file reading/writing: When updating a file, the target filesystem can compare the new and old files, and only transfer the modified portion of the file.

z Suitable for wireless environments: The target filesystem can tolerate the variation of wireless networks and consume less bandwidth.

NFS SMB Coda sshfs RSC MAFS

Persistent cache ╳ ╳ ○ ╳ ○ ○

Disconnected operation ╳ ╳ ○ ╳ ○ ○

Mobile authentication ╳ ○ ○ ○ ○ ○

Data encryption

╳ ╳ ○ ○ ╳ ╳

Standard protocols ○ ○ ╳ ○ ○ ╳

Differential file

reading/writing ╳ ╳ ╳ ╳ ╳ ╳

Suitable for wireless env. ╳ ╳ ╳ ╳ ○ ○

Table 1: Comparison of related works

Chapter 3 Design Issues

To realize a file system, there are some basic operations like read and write needed to be implemented. Because we want AshFS can support two key mechanisms: disconnected operation and automatic synchronization, these operations are slightly different than traditional ones. With a view to easing deployment, we adopt two design aspects used by RSC filesystem to develop AshFS: standardized protocol and no server-side changes, but we changed some designs. Here we are going to discuss them, and explain our design tenets.

3.1 Read Issues

Most mobile users do lots of read operations than write, and want their readings as fast as possible without being interfered with fluctuations of bandwidth.

Figure 1: Read flow

Figure 1 shows program flow of a read operation, and we are going to discuss some issues in detail. AshFS first search its cache for information of the requested object. At first time, there is a cache miss, AshFS will contact to server to get data. If the object has been read recently, it can be found in cache, so there is a cache hit. Then AshFS will check its validity, in order to make sure the cached data are fresh enough. Note that every network requests and replies will be sent to Network manager first. Because of unsteady connection of mobile networks, we have designed the network manager to facilitate administrating.

3.1.1 Cache design

In order to fully support disconnected operation, we designed a cache to store all necessary data and utilized whole-file caching; therefore user can still uses some files when there is no connection. Not only the object data are cached, but also its metadata are cached.

The metadata includes filename, size, owner, assess rights, last modification time, etc. which are needed for a file system to interpret its data. When the client access a file for the first time, the entire file is fetched and cached in the local file system. So next time when the same object is requested again, AshFS can answer it directly without contacting server.

The basic idea of AshFS is caching information which is needed of each filesystem operation and redirecting these operations to local disk first. Usually the operation of reading a new object returns until all needed data are fetched. However, users are always impatient of waiting for a long time and think that the program is crashed when fetching a large file. Hence AshFS times each read operation and returns immediately when timeout occurs. Fetching process will continue in background, and a message will be showed when someone tries to read this incomplete file.

Furthermore, AshFS supports persistent cache: The cache contents in memory will be

written into disk periodically in case of cache miss due to power shutdown or programs exits abnormally. Generally the user can use AshFS smoothly without being aware of the existence of cache, however we have make AshFS more flexible: The user can observe the caching state and control a part of cache.

3.1.2 Cache consistency

Because the client always refers to cached file preferentially, the freshness of the cached file becomes an important issue. If a cached file has been changed on the server, client should update this file before using it to prove data consistency; this process is called cache validation.

Traditionally cache validation can be avoided if the file in the server is locked. However, locking is overkill when the file is only opened for reading [3]. In fact, mobile clients usually perform much more reads than writes. Besides, file locking is not provided in the FUSE system [1], so the validity of the cache should be guaranteed by some other ways. One is server-side “callback”: The server actively notifies the client of changed files. This mechanism has been demonstrated to be a useful optimization in cache consistency management in many prior network file systems like Coda and NFSv4 [13]. Nevertheless, we have decided not to change server-side for easy deployment, also mobile network (like GPRS) operators do not typically allow active incoming packets form Internet [3]. So we have let the client to check validity actively: It check the last modification time of a file object on the server.

On the first time the client gets metadata of a file object (a file or a directory) from the server, it also records its last modification time, we say, time stamp in cache. Different from cache validation mechanism of RSC filesystem, we enhanced AshFS’s cache consistency by mixing both timeout (used in RSC) and check-on-demand mechanisms. The time stamp will be verified under two conditions: One is when the lifetime of the cached file object expires;

the other is when the object is requested. If the time stamp of a cached file object is different from server’s one, it means that server’s file have been modified since client have cached it last time. Maybe this cached file is out-of-date, and we call such file a “stale file”. If a cached file is marked as “stale”, AshFS will abandon it and try to download a fresher one.

Verifying cache needs to communicate with the server for every file operation, and it is bandwidth-consuming, so AshFS only perform it when it is in strongly connected state (discussed latter). In weakly connection state, AshFS’s control messages and file transfer deservedly take higher priority of network usage than cache validation. In addition, it’s apparent that such a communication process will take much more time than just deal with cached files. When considering the file operation speed, waiting until checking process finishes is unreasonable. So we do this process in parallel: create another thread to verify validity, and the main thread performs the real operation simultaneously. Main thread should detach his kid and returns quickly. If there is inconsistency, kid thread will mark this state on the file object, and update will be progressed next time. Checking validity in parallel sacrifices some consistency, but has a great advantage in operation speed. We used POSIX threads package (pthreads) [10] provided by the Linux OS to implement thread management and synchronization.

3.1.3 Network manager

AshFS is aware of the connection status, and divides it into three states: Strong, Weak, and Disconnected. When the connection to the server is lost, AshFS will switch to Disconnected mode automatically. In Disconnected mode, all file system operations will be served by cache, if there is a cache miss, an error message will be displayed. If the connection exists, but bandwidth is not strong enough, AshFS will switch to Weak mode. When AshFS is operated in Weak mode, it will still fetch the uncached file from the server, but all modifications will not be propagated to the server. Hence this stage is also called

write-disconnected mode.

As a matter of fact, AshFS’s every network accessing operation will past to Network manager first. Network manager is mainly responsible for identifying connection status, communicating with the server, and (re)connecting to the server. To classify connection status, Network manager uses timeout mechanism. Before Network manager connects to the server, a default timeout, say 20 seconds, was set. When it is connecting to the server, the response

As a matter of fact, AshFS’s every network accessing operation will past to Network manager first. Network manager is mainly responsible for identifying connection status, communicating with the server, and (re)connecting to the server. To classify connection status, Network manager uses timeout mechanism. Before Network manager connects to the server, a default timeout, say 20 seconds, was set. When it is connecting to the server, the response