• Abstract and Figures
• Public Full-text

Network-Aware Adaptation Techniques for Mobile File Systems Benjamin Atkin Kenneth P. Birman NEC Laboratories America Cornell University [email protected] [email protected] Abstract therefore react to bandwidth variations in a fine-grained man- ner. With real-life file system traffic featuring high read-write Wireless networks present unusual challenges for mobile file contention, MAFS is able to achieve improvements in execu- system clients, since they are characterised by unpredictable tion time of up to 10-20% at both low and high bandwidths. connectivity and widely-varying bandwidth. The traditional ap- proach to adapting network communication to these conditions is to write back file updates asynchronously when bandwidth is 2 Motivation low. Unfortunately, this can lead to underutilisation of band- width and inconsistencies between clients. We describe a new Mobile access to shared data is complicated by an unpredictable mobile file system, MAFS, that supports graceful degradation computing environment: the network or a particular destination of file system performance as bandwidth is reduced, as well as may be unavailable, or the throughput may be substandard, as rapid propagation of essential file updates. MAFS is able to shown in Figure 1. This graph shows results from packet-pair achieve 10-20% improvements in execution time for real-life measurements of available bandwidth between a mobile host file system traces featuring read-write contention. on a wireless network, and a wired host near the base station. As the mobile host moves, factors such as the distance to the base station and local interference cause the host's network 1 Introduction card to switch to higher-redundancy, lower-bandwidth encod- ings. Such switching causes available bandwidth to oscillate Distributed file systems are a common feature of large com- greatly, even when the mobile host is stationary. If it is to en- puting environments, since they simplify sharing data between sure that clients' file operations are executed in a timely way, a users, and can provide scalable and highly available file ac- file system must adapt to this variation. cess [4]. However, supporting mobile clients requires coping Existing systems tailored to low-bandwidth clients differen- with the atypical patterns of connectivity that characterise them. tiate between types of file system communication, so that band- While a desktop client is well-connected to a file server un- width can be devoted to important, user-visible operations [5, der most circumstances, a mobile client frequently lacks the 6, 9]. In particular, Coda [9] writes back changes to files asyn- bandwidth to perform all its file operations in a timely fashion. chronously, and Little Work [5] assigns lower priorities to asyn- Mobile file systems typically assume that a client is strongly- chronous operations at the IP level to reduce interference with connected like a desktop host, or weakly-connected and should foreground operations. limit its bandwidth consumption to a minimum [5, 9]. If band- However, adaptation by deferred transmission of file up- width lies between these extremes, assuming weak connectivity dates has the disadvantage of increasing the delay before up- can be too conservative, since it delays sending updates to the dates are applied at the file server, and therefore reduces the de- server in order to aggregate modifications. gree of consistency between clients' cached copies. For its own This paper examines the effectiveness of MAFS, a mobile benefit, a low-bandwidth client may decide to delay sending a file system that propagates file modifications asynchronously file’s update to the file server, but this decision may also affect at all bandwidth levels. Rather than delaying writes, MAFS other clients that would like to read the file. Optimistic concur- uses RPC priorities to reduce interference between read and rency control and reconciliation of conflicting updates are typ- write traffic at low bandwidth. To ensure that file modifications ically used to resolve inconsistencies [9, 11]. When bandwidth are rapidly propagated to the clients that need them, MAFS is very low, this can be an acceptable price to pay for the abil- also incorporates a new invalidation-based update propagation ity to continue accessing a file server, but if bandwidth is less scheme. Unlike previous mobile file systems, MAFS uses tech- constrained, better inter-client consistency is achievable. Coda- niques that are oblivious to the exact bandwidth level, and can like file systems therefore switch between a low-bandwidth, asynchronous-writes mode and a synchronous-writes mode, ac- The authors were supported in part by DARPA under AFRL grant RADC F30602-99-1-0532, and by AFOSR under MURI grant F49620-02-1-0233, cording to the available bandwidth. However, in a wireless with additional support from Microsoft Research and from the Intel Corpo- network, variations in bandwidth can occur without the user's ration. knowledge, so that changing modes creates unexpected incon- 1 800 several clients concurrently modify a file, the final contents de- 600 pend on the client that closed it last. A client can lock a file 400 to synchronise accesses: the server grants the client a lease [3] that is renewed each time the client communicates with the file 200 bandwidth (KB/s) server. 0 0 100 200 300 400 500 time (s) Figure 1: Time series of wireless bandwidth. 3.3 Adaptive Remote Procedure Call MAFS uses Adaptive Remote Procedure Call for client-server sistencies [2]. Adaptation based on low- and high-bandwidth communication. Adaptive RPC is based on our earlier work in modes can be ill-suited to situations where bandwidth is not network-aware communication adaptation [1], and differs from severely constrained, but insufficient for a client to ignore it a typical RPC system in allowing applications to control how when deciding what to send over the network. concurrent RPCs are transmitted, and special handling for fail- ures due to insufficient bandwidth. Adaptive RPC requests and replies can contain an arbitrary amount of data. A sender also 3 File system overview attaches a priority and timeout to the send operation. Like a Rover Queued RPC [6], an Adaptive RPC can be asynchronous, MAFS (Adaptive Mobile File System) is a distributed file sys- so that an application need not block waiting for the result: in- tem designed to support efficient access to a remote file server stead, the library makes an upcall when the reply arrives. by mobile clients that must cope with variations in available Since an application can perform multiple RPCs concur- bandwidth. The MAFS design and terminology are similar to rently, Adaptive RPC schedules their transmission: this corre- the Andrew File System [4] and Coda [9]. sponds to allocating bandwidth among the competing RPCs. Attaching priorities to RPCs allows applications to control this 3.1 File access model scheduling policy. A programmer divides RPCs into classes based on the importance of their results to the user, and then MAFS clients use whole-file caching: when a file is accessed assigns priorities to the classes. The library schedules RPCs for the first time, a client fetches the entire file from the file based on priorities whenever there is insufficient bandwidth to server and caches it. MAFS only sends the server the contents transmit competing RPCs without a noticeable delay. RPCs of a modified file when it is closed by an application: this is from higher-priority classes are performed first, and RPCs of referred to as writeback-on-close. Directory operations cache equal priority are performed in parallel. This ensures that the directory contents and apply changes locally, as well as mak- application adapts itself to the available bandwidth gracefully, ing an RPC to apply the changes to the server's copy. Whole since lower bandwidth translates into longer delays for lower- file caching is effective if a client's connectivity is uncertain, priority RPCs. RPC timeouts allow the application to prevent since the client can always use cached copies of files instead low-priority RPCs being silently starved. Using priorities al- of incrementally fetching them from the server. MAFS sup- lows a programmer to write an adaptive application without ports this type of disconnected operation [9], but not to the ex- having to take account of the actual bandwidth or current mix tent of automatic reconciliation of update conflicts [11]. On of RPCs at runtime, and avoid having to specify thresholds at the other hand, block-level caching reduces the delay incurred which it should switch communication modes. when an application opens a file, and, as has been shown in An RPC whose results are urgently required should be as- the Low-Bandwidth File System [10], it is possible to use a signed the highest priority, particularly if the RPC contains out- content-based division of files into blocks as the basis for re- of-band communication. Larger, but still important RPCs can ducing client-server network traffic. However, reducing client- use intermediate levels, while the lowest levels are useful for server traffic does not eliminate the fundamental problem of RPCs that can be arbitrarily delayed, such as speculative activ- contention for insufficient bandwidth. ities like prefetching and transferring archival data. If the ini- tial assumption regarding the correct priority level for an RPC 3.2 Inter-client cache consistency proves incorrect, a call to the library can be made to assign a new priority. When a client fetches a file, the file server grants it permis- sion to cache the file for a limited period, and adds it to a list 3.4 Implementation of clients that cache the file. If the client modifies and then closes the file, it transmits the new contents to the server, which MAFS is implemented in C on FreeBSD. The client is a user- makes a callback RPC to any other clients on the list.

Load more

  8

Copy Link