(a) MAY18 : “In Google File System (GFS) chunk servers are required to periodically check in

with the master node and also at system or chunk server start up.” Justify this statement
by evaluating the purpose of each task the chunk server performs with the master node in
the relevant context during this contact.

Ans: In Google File System (GFS), chunk servers are responsible for storing and managing
chunks of data that make up a file. The master node acts as the central coordinator in the
GFS architecture, managing metadata and coordinating operations among chunk servers.
The periodic check-ins and start-up tasks performed by chunk servers with the master node
serve important purposes in the GFS system.

Periodic Check-ins: Chunk servers in GFS are required to periodically check in with the
master node. This serves several purposes:

a. Heartbeat and Liveness Detection:

I. The periodic check-ins act as a heartbeat mechanism, allowing the master node to
determine if a chunk server is still alive and functioning properly.
II. If a chunk server fails to check in within a certain timeframe, the master node can
mark it as offline and take appropriate actions, such as re-replicating the data stored
on that chunk server to ensure data reliability and availability.

b. Chunk Server Load Monitoring:

I. The check-ins also allow the master node to monitor the load and status of each
chunk server.
II. The chunk servers report their current load and capacity to the master node
during the check-ins, allowing the master node to make informed decisions
about chunk server assignments and load balancing.
III. This helps in optimizing the performance and resource utilization of the overall
GFS system.

c. Metadata Synchronization:
I. The periodic check-ins also serve as an opportunity for the chunk server to
synchronize its metadata, such as chunk locations and versions, with the master
node.
II. This ensures that the master node has up-to-date information about the status
of each chunk and helps in maintaining consistency and integrity of the file
system.

Start-up Tasks:
 I. Chunk servers in GFS are also required to perform tasks during system or chunk
server start-up, which includes contacting the master node. This serves the
following purposes:

a. Registration and Initialization:

II. During start-up, a chunk server needs to register itself with the master node to
announce its presence and availability.
III. This allows the master node to keep track of all active chunk servers in the system
and maintain an updated list of available resources.

b. Metadata Retrieval:
I. The chunk server may also need to retrieve metadata from the master node
during start-up, such as the current version of chunks it is responsible for.
II. This ensures that the chunk server has the latest metadata and can correctly
serve read and write requests from clients.

c. Error Recovery:
I. If a chunk server experienced a failure or was offline for some time, contacting
the master node during start-up allows it to recover from any errors or
inconsistencies that may have occurred during its downtime.
II. The master node can provide necessary information and instructions for error
recovery, ensuring the chunk server can resume normal operation.

In summary,
I. The periodic check-ins and start-up tasks performed by chunk servers in GFS with
the master node serve critical purposes, including liveness detection, load
monitoring, metadata synchronization, registration, metadata retrieval, and error
recovery, which collectively contribute to the reliability, consistency, and
performance of the GFS system.

(b) Explain the role of checkpointing in the GFS parallel file system and how it is performed.
Compare and contrast how recovery would function if: (i) checkpointing exists in the
system and (ii) checkpointing did not exist in the system.

Ans: Checkpointing is an important mechanism in the Google File System (GFS) parallel file
system that helps to ensure data reliability and system resilience. It involves periodically
creating a snapshot of the system's state, including the metadata and data stored in the chunks,
and saving it to a stable storage location, typically on a different machine or storage medium. In
case of a failure or crash, the system can then use these checkpoints to recover and resume
normal operation.
  Role of Checkpointing in GFS:

1. Data Reliability:
 Checkpointing helps to maintain data reliability in GFS by creating consistent snapshots of the
system's state.
 It allows the system to recover from failures, such as hardware failures or software crashes, by
using the saved checkpoints to restore the metadata and data to a known good state.

2. System Resilience:
a) Checkpointing enhances the resilience of GFS by providing a recovery mechanism.
b) If a chunk server or a master node fails, the system can use the checkpoints to recover the lost
data and metadata, and restore the system to a consistent state.

Checkpointing Process in GFS:

The checkpointing process in GFS involves the following steps:

3. Snapshot Creation:
I. Periodically, GFS creates a snapshot of the system's state, including the metadata and
data stored in the chunks.
II. This snapshot is saved to a stable storage location, typically on a different machine or
storage medium, to protect against failures.

4. Metadata and Data Synchronization:

I. Before creating the snapshot, GFS ensures that the metadata and data are
synchronized.
II. This is done by coordinating with the master node and the chunk servers to flush any
pending writes and ensure that the metadata and data are consistent and up-to-date.

5. Snapshot Storage: The snapshot is stored in a stable storage location, such as a distributed file
system or a reliable storage medium, to ensure durability and accessibility even in the event of
failures.

 Recovery with Checkpointing vs. Recovery without Checkpointing:

 Checkpointing Exists in the System:

I. If checkpointing exists in the system, recovery from failures is relatively straightforward.
In case of a failure, the system can use the saved checkpoints to restore the metadata
and data to a known good state.
II. The recovery process involves identifying the most recent checkpoint, retrieving the
metadata and data from the checkpoint, and resuming normal operation from that
point.
 III. This helps in maintaining data integrity and system resilience, as the system can recover
from failures with minimal data loss and downtime.

(ii) Checkpointing Does Not Exist in the System:

I. If checkpointing does not exist in the system, recovery from failures can be more
complex and time-consuming.
II. In case of a failure, the system may need to rely on other mechanisms, such as
replication and re-computation, to recover the lost data and metadata.
III. This can result in data inconsistencies, longer recovery times, and increased system
downtime.
IV. The absence of checkpointing can also make it challenging to identify the exact state of
the system at the time of failure, leading to potential data loss or corruption.

In summary,
I. Checkpointing plays a crucial role in ensuring data reliability and system resilience in
GFS.
II. It provides a mechanism for creating consistent snapshots of the system's state, which
can be used for recovery in case of failures.
III. Without checkpointing, recovery from failures can be more complex and time-
consuming, and may result in data inconsistencies and increased system downtime.

(c) Explain the effect on network traffic in GFS by allowing processes to register for file
content modifications rather than polling for file changes.

Ans: Allowing processes in the Google File System (GFS) to register for file content
modifications instead of polling for file changes can have a significant impact on network
traffic.

 Polling for file changes involves regularly querying the file system to check if any
modifications have been made to a particular file. This can result in a high volume of
unnecessary network traffic, as the system needs to constantly send requests to the
file system, even if there are no actual changes to the file. This can lead to increased
network congestion and overhead, especially in large-scale distributed file systems
like GFS.
  On the other hand, allowing processes to register for file content modifications can
significantly reduce network traffic. Instead of polling, processes can simply register
their interest in specific files and be notified when changes occur. This can be done
through mechanisms such as file system notifications, callbacks, or event-driven
architectures.

The benefits of allowing processes to register for file content modifications include:

Reduced Network Traffic:

I. Registering for file content modifications eliminates the need for continuous
polling, which can result in a significant reduction in unnecessary network traffic.
II. Processes only receive notifications when changes actually occur, resulting in more
efficient and optimized network communication.

Lower Network Congestion:

I. With reduced network traffic, the overall network congestion is reduced.
II. This can lead to improved system performance and better utilization of network
resources, especially in large-scale distributed file systems like GFS where network
bandwidth is a critical factor.

Faster Response Time:

I. Registering for file content modifications enables processes to receive immediate
notifications when changes occur, allowing them to respond promptly.
II. This can result in faster response times and better real-time processing capabilities,
as processes can react to changes in near real-time without the need for continuous
polling.

Scalability:
I. Allowing processes to register for file content modifications can improve the
scalability of the system.
II. Polling can become a bottleneck in large-scale systems with a large number of
processes or files, whereas registering for notifications can distribute the load and
allow for more efficient handling of file modifications.

In summary,
I. Allowing processes to register for file content modifications instead of polling for file
changes can have a positive impact on network traffic in GFS.
II. It can reduce unnecessary network overhead, lower network congestion, improve
response times, and enhance the scalability of the system.
(d) MAY19 : (a) A cloud provider is currently designing a cloud storage system. Currently
they have decided to use cell storage over journalled storage. Explain how cell
storage and journal storage function, and how data is recovered in each storage
system. Discuss why journal storage is a better choice compared to cell storage for a
cloud.

Ans: Cell storage and journalled storage are two different approaches to managing data in a
storage system, and they have different mechanisms for data organization and recovery.

 Cell storage:
I. It is a method where data is divided into fixed-size chunks called cells, and each cell
is individually addressed and stored in separate locations across the storage system.
II. This approach allows for efficient distribution of data across multiple servers or
drives, and enables parallel processing of data.
III. However, cell storage does not typically provide built-in mechanisms for data
integrity, consistency, or recovery.

 On the other hand, journalled storage

I. It is a method where data is organized as a continuous log or journal, which captures
changes made to the data in a sequential manner.
II. Each change or update to the data is appended to the journal, creating a historical
record of modifications.
III. This approach provides built-in mechanisms for data recovery, as the journal can be
used to restore the data to a previous consistent state in case of failures or errors.

 Data recovery in cell storage:

I. It usually involves retrieving individual cells from their respective locations and
reconstructing the original data based on the metadata or addressing information
associated with each cell.
II. This process can be complex and time-consuming, especially in large-scale
distributed storage systems, as it requires coordination and synchronization across
multiple servers.

 In contrast, data recovery in journalled storage:

I. It usually involves using the journal to replay the recorded changes in the correct
order and restore the data to a consistent state.
II. This process is generally faster and more efficient, as it only requires replaying the
changes from the journal, rather than retrieving and reconstructing individual cells.

In the context of cloud storage, journalled storage is generally considered a better choice
compared to cell storage for several reasons:

 Data Integrity and Consistency:

I. Journalled storage provides built-in mechanisms for data integrity and consistency
through the use of a continuous log or journal.
II. This helps ensure that data remains consistent and reliable, even in the presence of
failures or errors.
  Efficient Data Recovery:
Journalled storage allows for faster and more efficient data recovery by replaying
recorded changes from the journal, rather than retrieving and reconstructing
individual cells. This can reduce downtime and improve system availability.

 Scalability and Manageability:

Journalled storage can be more scalable and manageable in large-scale distributed
cloud storage systems, as it provides a unified log or journal for capturing changes
across multiple servers or drives. This simplifies data management, replication, and
recovery processes.

 Flexibility and Extensibility: Journalled storage can be more flexible and

extensible, as it allows for adding new data management features or functionality by
extending the journal or log. This can enable future enhancements or optimizations to
the storage system without disrupting existing data.

In summary, journalled storage is generally considered a better choice compared to cell

storage for cloud storage systems due to its built-in mechanisms for data integrity, efficient
data recovery, scalability, manageability, flexibility, and extensibility.

(e) August19 : The same cloud provider has decided to physically locate their lock servers
in a single rack in their data centre with no backup network. Using the Chubby Lock
Server design as an example evaluate why this is a bad idea in the event of a physical
disaster in the data centre.

Ans: Locating the lock servers in a single rack in the data center with no backup network can
be a risky approach, especially in the event of a physical disaster in the data center. Let's
consider the Chubby Lock Server design, which is a distributed lock service designed by
Google, as an example.

In the Chubby Lock Server design, multiple lock servers are distributed across different
physical machines or racks to provide fault tolerance and high availability. These lock servers
collectively manage distributed locks that are used by applications or services to coordinate
access to shared resources or to maintain distributed state.

If all lock servers are located in a single rack with no backup network, several risks arise:

Single Point of Failure:

The single rack becomes a single point of failure for the entire lock service. In the event of a
physical disaster such as a power outage, network failure, or hardware failure in the rack, all
lock servers and the services that rely on them can become unavailable, leading to service
disruptions or failures.

Limited Redundancy:
 I. Without backup network connections, the lock servers in the rack may be vulnerable
to network failures or outages.
II. This can result in isolation or loss of connectivity, making the lock service
inaccessible or unreliable.

Data Loss Risks:

I. In the event of a physical disaster such as fire, flooding, or equipment damage in the
rack, the lock servers and their data may be at risk of permanent loss.
II. Without proper backup or replication mechanisms, critical data stored in the lock
service may be irretrievable, leading to data loss and potential data integrity issues.

Recovery Challenges:
I. In case of a physical disaster, recovery efforts for the lock service may be
complicated and time-consuming.
II. The lack of backup network connections may hinder the ability to restore the lock
service to normal operation, resulting in prolonged downtime and disruptions to the
applications or services that rely on the lock service.

Compliance and Security Risks:

I. Depending on the regulatory requirements and security policies of the cloud provider
and its customers, locating all lock servers in a single rack with no backup network
may violate compliance regulations or expose sensitive data to security risks.
II. For example, backup network connections may be required for data redundancy,
data protection, or disaster recovery purposes.

In conclusion,
I. Locating all lock servers in a single rack with no backup network can be a risky
approach in the event of a physical disaster in the data center.
II. It can lead to single point of failure, limited redundancy, data loss risks, recovery
challenges, and compliance/security risks, which can result in service disruptions,
data integrity issues, prolonged downtime, and non-compliance with regulations or
security policies.
III. Therefore, it is generally considered a bad idea to rely on a single rack with no
backup network for critical distributed services like lock servers in a cloud storage
system. Proper redundancy, backup, and disaster recovery mechanisms should be
in place to ensure high availability, data protection, and system resilience.

(f) MAY20 : “The master node in GFS can handle a high number of requests due to
operation offloading”. Defend this statement by explaining what operations are
offloaded and how they are offloaded.

Ans: The statement "The master node in GFS can handle a high number of requests due to
operation offloading" is justified by the fact that the Google File System (GFS) architecture
employs a technique called operation offloading to efficiently handle a large number of
requests.
In GFS, the master node is responsible for managing metadata, coordinating operations, and
maintaining the global namespace. However, to handle the massive scale of data and
requests in a distributed file system, GFS offloads certain operations from the master node to
other components in the system, which helps to alleviate the load on the master node and
enable it to handle a high number of requests.

There are several operations that are offloaded in GFS:

Data Operations:
I. The master node in GFS offloads the actual data reads and writes to the chunk
servers.
II. When a client needs to read or write data, it communicates directly with the
respective chunk server that holds the data, bypassing the master node.
III. This allows the master node to avoid being a bottleneck for data operations, and
enables clients to communicate directly with the chunk servers, improving the
scalability and performance of the system.

Metadata Operations:
I. GFS offloads some of the metadata operations to chunk servers.
II. For example, chunk servers are responsible for maintaining the mapping between
chunks and their corresponding chunk handles or file names.
III. This offloading of metadata operations allows the master node to delegate some of
the metadata management tasks to chunk servers, reducing the workload on the
master node.

Lease Management:
I. GFS uses a lease-based mechanism for managing concurrent access to files.
II. The master node grants leases to clients, allowing them to perform read or write
operations on a file for a certain period of time without needing to consult the master
node for every operation.
III. This offloading of lease management to clients allows the master node to avoid
being involved in every file access operation, reducing the overhead on the master
node and improving system scalability.

Replication and Re-replication:

I. GFS offloads the responsibility of data replication and re-replication to chunk
servers.
II. Chunk servers are responsible for making copies of chunks and maintaining the
desired level of replication across the system.
III. This offloading of replication and re-replication tasks from the master node allows it
to focus on other management tasks and handle a high number of requests
efficiently.

In summary, GFS achieves high scalability and performance by offloading various

operations from the master node to other components in the system, such as chunk servers
and clients. This allows the master node to handle a large number of requests by reducing its
workload and avoiding becoming a bottleneck in the system, which justifies the statement that
"The master node in GFS can handle a high number of requests due to operation offloading."
(g) August20 : In GFS the Chubby Lock System uses cells of 5 servers that have their
own network and are placed a large distance apart. Evaluate the reasons why these
design decisions were made and in your answer explain how locking works with this
system.

Ans: The design decisions of using cells of 5 servers in the Chubby Lock System in Google
File System (GFS) are based on several factors that are critical for achieving high availability
and fault tolerance in a distributed locking service.

Redundancy and Fault Tolerance:

I. The use of multiple servers in a cell ensures redundancy and fault tolerance.
II. By placing servers in a cell that are physically located a large distance apart, the
system can withstand failures such as network outages, power outages, or hardware
failures in a single location.
III. If one or more servers in a cell fail, the remaining servers can still continue to provide
the locking service, ensuring high availability and reliability of the system.

Geographic Distribution:
I. Placing servers in a cell that are physically located a large distance apart provides
geographic distribution.
II. This helps in minimizing the impact of regional disasters such as earthquakes,
floods, or fires that could potentially affect a single location.
III. By spreading the servers across different geographical locations, the system can
ensure that the locking service remains available even if one location is affected by a
disaster.

Scalability:
I. The use of cells with multiple servers allows for scalability. As the demand for the
locking service grows, additional servers can be added to the cell to handle
increased load.
II. This allows the system to scale horizontally and accommodate more clients and
locks without sacrificing performance or availability.

 In the Chubby Lock System, locking works by acquiring leases from the lock servers
in a cell. Clients that need to acquire a lock send requests to the lock servers, and
upon successful acquisition of the lock, the client is granted a lease for a certain
period of time.
 Clients can renew the lease before it expires to maintain ownership of the lock. If a
client fails or becomes disconnected, the lease will eventually expire, allowing other
clients to acquire the lock.

 The Chubby Lock System uses a majority-based approach for lock server operation.
 In a cell of 5 servers, a majority of at least 3 servers must agree on the state of a lock
or lease for it to be considered valid.
  This ensures that the system can tolerate failures of up to 2 servers while still
maintaining the availability and consistency of locks.

 In summary,

The design decisions of using cells of 5 servers in the Chubby Lock System in GFS
are aimed at achieving high availability, fault tolerance, geographic distribution, and
scalability. Locking in this system involves acquiring leases from lock servers, and
the majority-based approach ensures the reliability and consistency of locks even in
the presence of failures.

(h) MAY21 : Explain why chunk servers in GFS are required to periodically check in with the
master node. Summarise the tasks that are performed as part of this checkin.

Ans: In Google File System (GFS), chunk servers are required to periodically check in with the
master node to ensure proper functioning of the distributed file system and to provide
necessary updates to the master about the status of the chunks they are responsible for.
The periodic check-in allows the master node to maintain an up-to-date metadata about the
chunk locations and health status, and also enables the master to take corrective actions in
case of failures or changes in the system.

The tasks performed as part of the chunk server check-in with the master node include:

 Heartbeat: The chunk server sends a heartbeat message to the master node to
indicate that it is still operational. The heartbeat message contains information such
as the server's identification, timestamp, and its current status.

 Chunk Report: The chunk server provides a report to the master node about the
chunks it is currently storing. This includes information such as the list of chunks it
has, their locations, and their health status. The chunk server also reports any
changes in the chunk status, such as chunk failures, recoveries, or migrations.

 Rebalancing: If a chunk server has too many or too few chunks compared to other
chunk servers in the system, the master node may initiate chunk migration to
achieve load balancing. The chunk server check-in allows the master node to
identify such cases and trigger chunk migrations as needed.

 Lease Renewal: If the chunk server is holding a lease for a chunk, it needs to
periodically renew the lease by sending a lease renewal request to the master node.
The master node validates the lease and renews it if it is still valid, ensuring that the
chunk server continues to have ownership of the chunk.
  Failure Detection: The chunk server check-in allows the master node to detect
failures of chunk servers. If a chunk server fails to check in within the expected
timeframe, the master node can mark it as failed and take necessary actions, such
as re-replicating the chunks it was responsible for, to ensure data durability and
availability.

In summary,
The periodic check-in of chunk servers with the master node in GFS serves multiple
purposes, including maintaining up-to-date metadata, enabling load balancing, renewing
leases, and detecting failures, to ensure the proper functioning and reliability of the
distributed file system.

(i) August21 : While working on a filesystem for a cloud you discover that it uses checksums
to ensure chunk consistency. However you notice that only two copies of each chunk is
maintained at all times. After explaining how checksums are used to ensure consistency
explain why having two copies is a bad idea and suggest a solution. Analyse any side
effects of your solution.

Ans: Checksums are used in cloud file systems to ensure the consistency and integrity of
data stored in chunks. A checksum is a fixed-size hash value computed from the content of a
chunk, and it is used as a fingerprint to detect changes or corruption in the chunk.

 In a cloud file system where only two copies of each chunk are maintained, using
checksums for consistency checking can be insufficient and may not provide
adequate data durability and reliability.
 This is because with only two copies, there is a higher risk of data loss or corruption
due to hardware failures, network failures, or other issues.

The use of checksums alone in a system with only two copies of each chunk is not enough to
ensure data consistency because if one of the two copies becomes corrupted or unavailable,
there is no additional copy to verify against. As a result, the system may not be able to
detect and correct errors, leading to potential data inconsistency or loss.

To address this issue, one solution could be

I. to increase the number of copies of each chunk to provide higher levels of
redundancy.
II. For example, instead of maintaining only two copies, the system could maintain
multiple copies, such as three or more, to provide better fault tolerance.
 III. This way, if one or even two copies become corrupted or unavailable, there are still
additional copies available for verification against the checksums.

However, increasing the number of copies also has some side effects,
I. such as increased storage overhead and higher network traffic for data replication.
Additional storage space and bandwidth may be required to maintain the extra
copies, resulting in increased costs.
II. Moreover, the increased network traffic for data replication may impact the
performance and latency of the system, especially in large-scale cloud storage
environments with high data throughput.

In summary,
I. while checksums can be used to ensure chunk consistency in cloud file systems,
relying on only two copies of each chunk may not provide sufficient data durability
and reliability.
II. Increasing the number of copies of each chunk can be a solution to enhance fault
tolerance, but it may also have side effects such as increased storage overhead and
network traffic.
III. A trade-off between data durability, cost, and performance needs to be carefully
considered when designing a cloud file system.

May22. Summarise how a file write occurs in Google File System. Analyse the effects this system has
on chunk consistency and file reads.

Ans:

 In Google File System (GFS), a file write occurs in the following steps:
 The client sends a write request to the master node, specifying the file name, the offset where
the write should occur, and the data to be written.
 The master node determines the location of the corresponding chunk(s) that contains the data
to be written based on the file's metadata.
 The client sends the write request directly to the chunk server(s) that holds the relevant
chunk(s).
 The chunk server(s) stores the data in the chunk(s) and acknowledges the write request to the
client.
 The client may optionally send a record append request to the master node to update the
append pointer in the file's metadata.
 o The GFS system has several effects on chunk consistency and file reads:

 Chunk consistency:
1. GFS uses checksums to ensure chunk consistency.
2. When a chunk server receives a write request, it verifies the checksum of the written
data to detect any data corruption.
3. If a checksum mismatch is detected, the chunk server attempts to recover the data
from other replicas.
4. This helps maintain the consistency and integrity of data stored in chunks in GFS.

 File reads:
1. File reads in GFS can be performed in parallel from multiple replicas of a chunk, allowing
for high read throughput.
2. The system is optimized for streaming reads, which are common in large-scale data
processing scenarios.
3. However, random reads can be slower due to the overhead of contacting multiple
replicas and coordinating among them.

 Caching:
1. GFS employs a client-side caching mechanism to improve read performance.
2. Once a client reads data from a chunk, it caches the data locally, reducing the need to
read the same data from the chunk server again.
3. However, this caching mechanism introduces potential consistency issues, as the client
may read stale data from its cache that does not reflect the most recent writes to the
chunk.

In summary,

1. GFS's file write process ensures chunk consistency through the use of checksums and
replication, and file reads can be performed in parallel from multiple replicas for high
throughput.
2. However, caching mechanisms may introduce consistency challenges in certain scenarios, and
random reads may have performance overheads due to the need to contact multiple replicas.

Aug22 .(a) Justify why in Google File System the chubby lock servers are placed a large physical
distance apart and have their own separate communication network. If a chubby node has a failure
rate of 1% what evaluate the probability that all 5 would fail at the same time.
Ans:

 In Google File System (GFS), the Chubby Lock System uses a design where chubby lock servers
are placed a large physical distance apart and have their own separate communication network
for several reasons:

1. Fault tolerance:
I. Placing chubby lock servers at a large physical distance apart reduces the risk of a single
point of failure.
II. If all chubby lock servers were colocated in the same location, a single disaster, such as
a fire or a power outage, could potentially affect all of them simultaneously, leading to a
complete lock service outage.
III. By spreading chubby lock servers across multiple physical locations, GFS increases the
system's fault tolerance and ensures availability even in the face of local failures.

2. Redundancy:
I. Having chubby lock servers in separate physical locations allows for redundancy.
II. If one chubby lock server fails, the other chubby lock servers can continue to provide
lock services and maintain system availability.
III. GFS typically uses multiple replicas of the same lock data on different chubby lock
servers, so even if one or more chubby lock servers fail, the system can still function
without interruption.

3. Isolation:
I. Separating the communication network for chubby lock servers from the rest of the GFS
system helps to isolate the lock service from potential performance or security issues in
the main GFS network.
II. Chubby lock servers are critical for coordinating distributed operations, and having a
dedicated communication network for them can ensure that their communication is not
impacted by other factors in the system.

 Now, assuming a chubby node has a failure rate of 1%, the probability that all 5 chubby lock
servers would fail at the same time can be calculated using the probability of independent
events.
 The probability of a single chubby lock server failing is 1% or 0.01.
 The probability of all 5 chubby lock servers failing simultaneously is the product of the individual
failure probabilities:

 Probability of all 5 chubby lock servers failing = (0.01)^5 = 0.00000001 or 0.000001%

 So, the probability of all 5 chubby lock servers failing at the same time is extremely low,
indicating a high level of fault tolerance and redundancy in the design of the Chubby Lock
System in GFS.