Atharva Thakur 221042007 72

Experiment No: 9

Aim: Case Study of Distributed File Systems: AFS (Andrew File System) and CODA

Distributed File Systems (DFS) are designed to allow multiple users to access and share files
across a network in a way that looks and feels like a local file system. AFS (Andrew File
System) and CODA are two prominent DFS that have been widely discussed and studied for
their design and impact on distributed computing. Below is a detailed case study of both
systems, exploring their architectures, design principles, strengths, weaknesses, and use
cases.

1. Andrew File System (AFS)

Overview

The Andrew File System (AFS) was developed at Carnegie Mellon University in the 1980s
and is one of the most well-known examples of a distributed file system. AFS was designed
with the aim of providing high performance, scalability, and transparency for users accessing
files across a wide-area network.

Key Features and Design Principles

• Client-Server Architecture: AFS uses a client-server architecture, where files are

stored on dedicated servers and accessed by clients. AFS clients access the file system
through a local cache, and the servers store the actual file data.
• Global Namespace: One of the key goals of AFS is to provide a global namespace for
all files. This allows users to access files using the same path, regardless of the
physical location of the file.
• Caching for Performance: AFS employs a caching mechanism on the client-side to
reduce the latency of accessing files. Files that are accessed frequently are cached
locally, so subsequent accesses can be served from the cache instead of over the
network.
• File Replication: To improve fault tolerance and availability, AFS supports file
replication. Files can be replicated on multiple servers, so if one server goes down,
another replica of the file can be served without interruption.
• Security and Authentication: AFS relies on a centralized authentication system called
Kerberos, which ensures that only authorized users can access certain files or
directories.
• Scalability: The AFS design emphasizes scalability, allowing it to handle large
numbers of clients across geographically distributed locations.

Components of AFS

1. File Servers: These servers store the actual file data. They handle file requests, such as
reading, writing, and modifying files.
2. AFS Clients: Clients use the AFS file system as though it is a local file system. They
can access, create, and modify files just as they would with a traditional file system.
AFS clients employ local caching to enhance performance.
Atharva Thakur 221042007 72

3. Volume Management: Files are divided into volumes in AFS. A volume is a collection
of directories and files stored on a single server. Volumes allow easier management of
data by creating logical partitions for data storage.
4. File and Directory Structure: AFS provides a hierarchical directory structure that is
globally accessible. The global namespace means that any file can be accessed by any
client, regardless of its physical location on the network.
5. Authentication: AFS uses Kerberos authentication to ensure secure and authenticated
access to the file system.
6. Cache Manager: Each AFS client has a Cache Manager that is responsible for caching
files locally, thereby improving performance and reducing load on the server.

Advantages of AFS

• Transparency: AFS provides a transparent user experience, where users do not need to
know the physical location of the files.
• Performance: The use of client-side caching reduces network load and improves
access times for frequently used files.
• Scalability: The system was designed to scale well across large numbers of clients and
geographically distributed locations.
• Security: AFS's use of Kerberos for authentication provides a robust security
mechanism.

Disadvantages of AFS

• Complex Setup: Setting up AFS requires a significant amount of administrative work,

especially when managing authentication and server configuration.
• Single Point of Failure: The centralized file server model can lead to bottlenecks or
single points of failure, especially for highly popular files.
• Caching Issues: Cache consistency can be an issue in AFS. Since clients rely on
locally cached data, ensuring that the data is up-to-date and synchronized can be
challenging.
Atharva Thakur 221042007 72

• Replication Limitations: While AFS supports replication, managing multiple copies of

large files across geographically distributed locations can be complex and
resourceintensive.
2. CODA File System

Overview

The CODA file system was developed as an extension of AFS and is designed to provide
high availability and fault tolerance in the face of network partitions or server crashes. CODA
was developed by Carnegie Mellon University as well, with an emphasis on mobile
computing and improving AFS's handling of network partitions.

Key Features and Design Principles

• Disconnected Operation: One of the most significant advancements CODA introduced

was the concept of disconnected operation. This allows clients to continue working
even when they are disconnected from the server (for example, when working on a
laptop in a remote location).
• Client Caching and Write-Back: CODA uses aggressive client-side caching of files.
When a client is disconnected from the server, it continues to make local changes to
cached files, which are then written back to the server once the connection is restored.
• Replication and Fault Tolerance: CODA provides more advanced replication
mechanisms compared to AFS. It supports server replication, allowing copies of files
to be distributed across multiple servers. This improves fault tolerance in the event of
a server failure.
• Server-based and Client-based Data Consistency: CODA employs a combination of
server-based and client-based data consistency mechanisms to ensure that all clients
are working with the most up-to-date version of a file once the client reconnects to the
server.
• Security: Similar to AFS, CODA also uses Kerberos for authentication and secure file
access.
• Scalability: CODA is designed to scale to a large number of clients and to handle the
dynamic nature of mobile devices with intermittent network connectivity.

Components of CODA

1. Coda Server: These are the central servers that store files and maintain file metadata.
A server in CODA is responsible for ensuring data consistency and managing
replication.
2. Coda Client: The client caches files locally for offline use and ensures data is
synchronized when the client reconnects to the network.
3. Cache Manager: Like AFS, CODA clients have a Cache Manager that is responsible
for caching data, ensuring that files are available even when the client is disconnected.
4. Volume Management: CODA uses a volume-based storage model, similar to AFS, to
manage the storage of files.
5. Replication Manager: CODA has a Replication Manager that ensures files are
replicated across multiple servers, enhancing fault tolerance and reducing server load.
6. Authentication: CODA relies on Kerberos authentication for access control and secure
file access.
Atharva Thakur 221042007 72

Advantages of CODA

• Disconnected Operation: CODA allows clients to continue working even when

disconnected from the server. This feature is crucial for mobile users and fieldwork
applications.
• Improved Fault Tolerance: By supporting replication and automatic failover, CODA
ensures that data remains accessible even in the event of server failures.
• High Availability: The combination of replication and disconnected operation makes
CODA highly resilient and available.

Disadvantages of CODA

• Cache Consistency: While CODA supports write-back caching, ensuring consistency

between the client cache and the server's data can become complex, especially when
there are conflicting updates.
• Performance Overheads: The system’s replication and caching mechanisms introduce
overheads, which can degrade performance in environments with frequent network
partitions or failures.
• Complexity: The synchronization and consistency mechanisms can make CODA more
complex to deploy and manage compared to other DFS.

Compare: AFS & CODA

Feature AFS CODA
Architecture Uses a client-server model where Also follows a client-server model
central file servers manage data, but introduces features for
and clients access files with local disconnected operation, where
caching. clients can work offline and
synchronize later.
Caching Caches files on the client side, but Caches files on the client side with
cache consistency is managed support for offline operation. Uses
through server validation. Clients a write-back cache mechanism,
must check the server to ensure allowing clients to continue
cache validity. working offline and sync changes
once the network is restored.
Scalability Scales well in environments with Scales effectively in mobile or
always-connected clients. Its distributed environments where
centralized architecture can face clients may frequently disconnect.
bottlenecks in large-scale, However, the complexity of
distributed systems. managing disconnected operations
can add overhead.
Atharva Thakur 221042007 72

Fault Tolerance Provides basic file replication Provides automatic recovery from
and Availability across servers for fault tolerance, network partitions and supports
but lacks automatic recovery from client disconnection, allowing
network partitions or client clients to work offline and replicate
disconnections. changes when reconnected. It uses
more advanced file replication and
fault tolerance.

Conclusion

Both AFS and CODA were groundbreaking in their time and continue to influence distributed
file systems today. AFS was designed for scalability and transparency in a research and
academic environment, whereas CODA extended AFS's design to handle issues like network
partitions, disconnected operation, and enhanced fault tolerance.

• AFS is a great choice for centralized environments where clients are generally always
connected, such as large university campuses or enterprise intranets.
• CODA, with its focus on disconnected operation and fault tolerance, is ideal for
environments with mobile or intermittent network access, such as for remote
fieldwork or mobile computing.

While both systems have been largely superseded by more modern DFS solutions (e.g., Ceph,
Google File System, HDFS), they remain important historical examples that laid the
groundwork for many of the features and capabilities in today's distributed systems.
Atharva Thakur 221042007 72

Experiment No: 10

Aim: Case Study on Android Stack

The Android Stack is a comprehensive software architecture that powers Android devices,
providing the framework for building and running mobile applications. Android, developed
by Google, is an open-source operating system for mobile devices, with over 70% market
share globally. This case study provides a detailed analysis of the Android Stack, breaking
down its key components and how they contribute to the overall system.

Overview of the Android Stack

The Android Stack is built on a multi-layered architecture that includes the Linux kernel, the
hardware abstraction layer (HAL), the Android runtime, libraries, and the application
framework. On top of this stack, you have the applications (including both system apps and
user apps).

The stack can be divided into five major layers, each with a specific responsibility in the
system:

1. Linux Kernel

The Linux Kernel forms the foundation of the Android operating system. It provides the
essential services needed for device hardware abstraction, memory management, and process
scheduling. The kernel is responsible for managing the system’s hardware resources and
ensuring that the operating system runs efficiently.

Key Functions of the Linux Kernel:

• Hardware Abstraction: Handles interaction with hardware devices such as Wi-Fi,

Bluetooth, camera, etc.
• Memory Management: Manages RAM and ensures that apps and processes do not
interfere with each other’s memory.
• Process Management: Handles the scheduling of processes and ensures that the CPU
is utilized efficiently.
• Security: Implements security features like access control and memory protection.
Atharva Thakur 221042007 72

• Networking: Manages network access and ensures proper communication across

wireless networks.

Important Components in the Kernel:

• Drivers: For hardware components like display, touchscreen, and sensors.

• Security Module: Implements access control and sandboxing of apps.
• Power Management: Helps optimize battery usage.

2. Hardware Abstraction Layer (HAL)

The Hardware Abstraction Layer acts as a bridge between the hardware and the software
running on Android. The HAL defines standard interfaces that the system can use to access
hardware without needing to understand the underlying specifics of the hardware. This
separation allows Android to run on different hardware platforms.

Key Functions of HAL:

• Hardware Interface: Provides an abstraction for the device’s hardware like sensors,
camera, Bluetooth, etc.
• Interfacing with Drivers: Communicates with drivers in the kernel to interact with the
actual hardware.
• Modularity: HAL makes it easier to implement platform-specific features by keeping
the core system independent of hardware.

Example HAL Components:

• Camera HAL: Provides interfaces to interact with the camera hardware.

• Sensor HAL: Abstracts sensor data from devices like accelerometers and gyroscopes.

3. Android Runtime (ART) and Libraries

Android apps are primarily written in Java (or Kotlin), but to run on Android devices, they
need to be compiled into an intermediate format. The Android Runtime (ART) executes these
compiled applications. ART is the successor of the Dalvik Virtual Machine (DVM) and was
introduced to improve performance and reduce power consumption.

Key Components of Android Runtime:

• ART (Android Runtime): A runtime environment that runs Java-based applications.

ART uses Ahead-of-Time (AOT) compilation to compile bytecode into native
machine code upon installation, improving app performance. ART was introduced to
replace Dalvik and brought significant improvements to speed and memory usage.
• Dalvik: The earlier runtime, which uses Just-In-Time (JIT) compilation to convert
bytecode to machine code on the fly, was phased out with ART.
• Garbage Collection (GC): ART manages memory by automatically reclaiming unused
memory blocks, preventing memory leaks in Android apps.
• Libraries: The Android system provides essential libraries to support application
development. These libraries include:
Atharva Thakur 221042007 72

o Libc: Standard C library, providing system-level functions.

o WebKit: A web browser engine that provides support for web-based content in
apps.
o OpenGL ES: Provides APIs for rendering 2D and 3D graphics. o SQLite: A
relational database library used to store app data.
o SSL/TLS Libraries: For secure communication and encryption.

4. Application Framework

The Application Framework is the layer that provides the essential tools and APIs for
developers to build Android applications. It contains all the necessary components that help
developers access the underlying system services.

Key Components of the Application Framework:

• Activity Manager: Manages the lifecycle of activities and provides navigation

between them. It also handles tasks like memory management.
• Window Manager: Manages the display of windows, which are the basic building
blocks of the user interface.
• Content Providers: Allow access to shared data from other applications (such as
contacts, messages, etc.) in a secure manner.
• Resource Manager: Handles the loading and management of resources such as strings,
layouts, and images.
• Notification Manager: Manages notifications that alert users to important events, such
as messages or updates.
• Package Manager: Provides access to information about installed applications and
manages the installation, updating, and removal of apps.
• Location Manager: Provides location-related services, using GPS or network-based
positioning.
• Telephony Manager: Manages phone call and SMS functionality.

5. Applications

At the top of the Android stack, the Applications Layer is where end-users interact with the
system. Android devices come pre-installed with system apps (such as Phone, Messaging,
Contacts, Camera, etc.), and users can install additional third-party apps from the Google
Play Store.

Key Aspects of Applications:

• User Interface: Apps are designed using XML layout files and the Android
framework’s View class, which manages UI elements.
• Activity: The fundamental unit of user interaction in an Android app. An activity
represents a single screen with which users can interact.
• Services: Apps can run background processes using services, such as playing music or
performing network operations.
• Broadcast Receivers: These components listen for system-wide events (e.g., when a
phone is charging or when Wi-Fi is connected) and can trigger actions in apps.
• Content Providers: Enable sharing of data between different apps in a secure manner.
Atharva Thakur 221042007 72

Advantages of the Android Stack

1. Open-Source: The Android stack is open-source, allowing developers to modify and

customize the platform.
2. Flexibility: The architecture allows Android to run on a wide range of hardware
devices with different configurations and capabilities.
3. Extensive Libraries and APIs: Android offers a large collection of libraries and APIs
for developers to use, including access to hardware, networking, and user interfaces.
4. App Ecosystem: Android's app ecosystem is one of the largest in the world, with
millions of apps available via the Google Play Store.
5. Multitasking and Background Services: Android supports multitasking, allowing
multiple apps to run concurrently in the background, with efficient power
management.
6. Security: Android provides multiple layers of security, from the Linux kernel's access
control to app sandboxing and permission-based access for system services.

Challenges and Limitations

1. Fragmentation: The Android ecosystem includes a wide variety of devices with

different screen sizes, hardware configurations, and OS versions, leading to
fragmentation challenges for developers.
2. Battery Consumption: Due to the high level of background services and multitasking,
Android devices may face issues with battery life, especially on older hardware.
3. Security Concerns: Despite security mechanisms, the open-source nature and
appbased permissions can lead to vulnerabilities, especially if apps are not properly
sandboxed or permissions are misused.
4. Performance Optimization: Although ART improves performance, managing
resource-intensive apps (e.g., games or media apps) on lower-end devices remains
challenging.

Conclusion

The Android Stack is a powerful and flexible system that has enabled Android to become the
most widely used mobile OS globally. Its layered architecture ensures that the system is
highly adaptable to various hardware configurations while providing developers with robust
tools and APIs to build feature-rich applications. However, challenges like fragmentation,
security, and battery management remain significant areas for improvement. Despite these
challenges, Android's open-source nature, extensive libraries, and massive app ecosystem
continue to make it a popular choice for both developers and consumers worldwide.