CODA
AMBRISH GANGAL
Whats coming up…..
Transferring data from a sender to a single receiver or
many receivers is not enough.
Only applications make a communication network useful.
Examples are file systems, databases, security, accounting
and billing mechanisms.
As mobile devices have limited energy resources, power
consumption is an important issue.
Focus point…
• This topic focuses on two aspects, file
systems/file synchronization and access to the
world wide web (www).
• Some years ago, many research projects dealt
with the problems of distributed file systems.
Some focused on the support of mobile devices,
low bandwidth wireless links, and disconnected
operation.
The main problem for distributed, loosely
coupled file systems is the maintenance of
consistency.
Additional problems….
• The general goal of a file system is to support
efficient, transparent, and consistent access to
files, no matter where the client requesting
files or the server(s) offering files are located.
• Efficiency is of special importance for wireless
systems as the bandwidth is low so the
protocol overhead and updating operations
etc. should be kept at a minimum.
• Transparency addresses the problems of
location- dependent views on a file system.
To support mobility, the file system should provide
identical views on directories, file names, access rights
etc., independent of the current location.
Problem …
Standard file systems like the network file system (NFS) are very inefficient
and almost unusable in a mobile and wireless environment (Honeyman,
1995).
Traditional file systems do not expect disconnection, low bandwidth
connections, and high latencies.
To support disconnected operation, the portable device may replicate files or
single objects. This can be done in advance by prefetching or while fetching
data (caching). The main problem is consistency of the copy with the original
data.
Consistency ??
• The basic problem for distributed file systems
that allow replication of data for performance
reasons is the consistency of replicated objects
(files, parts of files, parts of a data structure etc.).
• What happens, for example, if two portable
devices hold copies of the same object, then one
device changes the value of the object and after
that, both devices read the value? Without
urther mechanisms, one portable device reads
an old value.
Coda (Constant Data Availability)
Disconnected clients work only on the cache, i.e., applications use only
cached replicated files. Figure shows the cache between an application and
the server. Coda is a transparent extension of the client’s cache manager.
This very general architecture is valid for most of today’s mobile systems that
utilise a cache.
States of a client in CODA
States cont………
• Figure illustrates the three states of a client in Coda.
• The client only performs hoarding while a strong
connection to the server exists.
• If the connection breaks completely, the client goes
into emulating and uses only the cached replicates.
• If the client loses the strong connection and only a
weak connection remains, it does not perform
hoarding, but decides if it should fetch the file in case
of a cache miss considering user patience and file type.
The weak connection, however, is not used for
reintegration of files.
hoarding
• To provide all the necessary files for disconnected
work, Coda offers extensive mechanisms for pre-
fetching of files while still connected, called
hoarding.
• If the client is connected to the server with a
strong connection (see Figure) hoarding
transparently pre-fetches files currently used.
• This automatic data collection is necessary for it
is impossible for a standard user to know all the
files currently used.
• While standard programs and application data may be familiar to a
user, he or she typically does not know anything about the
numerous small system files needed in addition (e.g., profiles,
shared libraries, drivers, fonts).
• A user can pre-determine a list of files, which Coda should explicitly
pre-fetch.
• Additionally, a user can assign priorities to certain programs.
• Coda now decides on the current cache content using the list and a
least-recently-used (LRU) strategy.
• As soon as the client is disconnected, applications work on the
replicates (see Figure, emulating).
• Coda follows an optimistic approach and allows read and write
access to all files.
• The system keeps a record of changed files, but does not maintain a
history of changes for each file.
What if file is changed ??
• The cache always has only one replicate
(possibly changed). After reconnection, Coda
compares the replicates with the files on the
server as described in Kistler (1992).
• If Coda notices that two different users have
changed a file, reintegration of this file fails
and Coda saves the changed file as a copy on
the server to allow for manual reintegration.
Problem in CODA ?
Queries ??
