GOOGLE FILE SYSTEM

INTRODUCTION
Designed by Sanjay Ghemawat , Howard Gobioff and Shun-Tak

Leung of Google in 2002-03.
Provides fault tolerance, serving large number of clients with
high aggregate performance.
The field of Google is beyond the searching.
Google store the data in more than 15 thousands commodity
hardware.
Handles the exceptions of Google and other Google specific
challenges in their distributed file system.

DESIGN OVERVIEW
Assumptions
From many inexpensive commodity components that often

fail.
Stores a modest number of large files.
Workloads consist of large streaming reads and small

random reads.
Workloads also have many large, sequential writes that
append data to files.
Efficiently implement well-defined semantics for multiple
clients.
High sustained bandwidth is more important than low latency.

GOOGLE FILE SYSTEM ARCHITECTURE
GFS cluster consists of a single master and multiple
chunkservers.
The basic analogy of GFS is master , client , chunkservers.

Files are divided into fixed-size chunks.
Chunkservers store chunks on local disks as Linux files.
Master maintains all file system metadata.
Includes the namespace, access control information, the
mapping from files to chunks, and the current locations of
chunks.
Clients interact with the master for metadata operations.
Chunkservers need not cache file data .

Chunk
Similar to the concept of block in file systems.
Compared to file systems, the size of chunk is 64 MB.
Less chunks and less metadata for chunks in the master.
Problem in this chunk size is developing a hotspot.
Property of chunk is chunks are stored in chunkserver as
file, chunk handle, i.e., chunk file name.

Metadata
Master stores three major types of metadata: the file and
chunk namespaces, the mapping from files to chunks, and
the location of each chunk’s replicas.

First two types are kept persistent to an operation log stored
on the master’s local disk.
Metadata is stored in memory, master operations are fast.

Easy and efficient for the master to periodically scan .
Periodic scanning is used to implement chunk garbage
collection, re-replication and chunk migration .

Master
Single process ,running on a separate machine that stores
all metadata.
Clients contact master to get the metadata to contact the
chunkservers.

SYSTEM INTERACTION
Read Algorithm
1. Application originates the read request

2. GFS client translates the request form (filename, byte range) -> (filename,
chunk index), and sends it to master
3. Master responds with chunk handle and replica locations (i.e. chunkservers
where the replicas are stored)

4. Client picks a location and sends the (chunk handle, byte range) request to the

location
5. Chunkserver sends requested data to the client
6. Client forwards the data to the application

Write Algorithm
1. Application originates the request
2. GFS client translates request from (filename, data) -> (filename, chunk index),

and sends it to master
3. Master responds with chunk handle and (primary + secondary) replica
locations

4. Client pushes write data to all locations. Data is stored in chunkservers’
internal buffers

5. Client sends write command to primary

6. Primary determines serial order for data instances stored in its buffer and
writes the instances in that order to the chunk
7. Primary sends the serial order to the secondaries and tells them to perform the
write

8. Secondaries respond to the primary
9. Primary responds back to the client

Record Append Algorithm
1. Application originates record append request.
2. GFS client translates requests and sends it to master.
3. Master responds with chunk handle and (primary + secondary) replica locations.
4. Client pushes write data to all replicas of the last chunk of the file.
5. Primary checks if record fits in specified chunk.
6. If record doesn’t fit, then the primary:
Pads the chunk
Tell secondaries to do the same

And informs the client
Client then retries the append with the next chunk
7. If record fits, then the primary:
Appends the record
Tells secondaries to write data at exact offset
Receives responses from secondaries
And sends final response to the client

MASTER OPERATION
Name space management and locking
Multiple operations are to be active and use locks over regions of the

namespace.
GFS does not have a per-directory data structure.
GFS logically represents its namespace as a lookup table.
Each master operation acquires a set of locks before it runs.

Replica placement
A GFS cluster is highly distributed.
The chunk replica placement policy serves , maximize data reliability and
availability, and maximize network bandwidth utilization.

Chunk replicas are also spread across racks.

Creation , Re-replication and Balancing Chunks
Factors for choosing where to place the initially empty replicas:
(1)We want to place new replicas on chunkservers with below-average disksp
ace utilization.
(2) We want to limit the number of “recent” creations on each chunkserver.
(3)Spread replicas of a chunk across racks.
master re-replicates a chunk.
Chunk that needs to be rereplicated is prioritized based on how far it is from its
replication goal.
Finally, the master rebalances replicas periodically.

GARBAGE COLLECTION
 Garbage collection at both the file and chunk levels.
 Deleted by the application, the master logs the deletion

immediately.
 File is just renamed to a hidden name .
 The file can be read under the new, special name and can be

undeleted.
 Memory metadata is erased.

FAULT TOLERANCE
High Availability
Fast Recovery
Chunk Replication
Master Replication

Data Integrity
Chunkserver uses checksumming.
Broken up into 64 KB blocks.

CHALLENGES
 Storage size.
 Bottle neck for the clients.
 Time.

CONCLUSION
Supporting large-scale data processing.
Provides fault tolerance.
Tolerate chunkserver failures.
Delivers high throughput.
Storage platform for research and development.

GOOGLE FILE SYSTEM

More Related Content

What's hot (20)

Similar to GOOGLE FILE SYSTEM (20)

Recently uploaded (20)

GOOGLE FILE SYSTEM

Editor's Notes