The Google File System

wangfans

The system must efficiently implement well-defined semantics
for multiple clients that concurrently append
to the same file. Our files are often used as producerconsumer
queues or for many-way merging. Hundreds
of producers, running one per machine, will concurrently
append to a file. Atomicity with minimal synchronization
overhead is essential. The file may be
read later, or a consumer may be reading through the
file simultaneously.

wangfans

The system must efficiently implement well-defined semantics
for multiple clients that concurrently append
to the same file. Our files are often used as producerconsumer
queues or for many-way merging. Hundreds
of producers, running one per machine, will concurrently
append to a file. Atomicity with minimal synchronization
overhead is essential. The file may be
read later, or a consumer may be reading through the
file simultaneously.

wangfans

High sustained bandwidth is more important than low
latency. Most of our target applications place a premium
on processing data in bulka t a high rate, while
few have stringent response time requirements for an
individual read or write.

wangfans

2.2 Interface
GFS provides a familiar file system interface, though it
does not implement a standard API such as POSIX. Files are
organized hierarchically in directories and identified by pathnames.
We support the usual operations to create, delete,
open, close, read, and write files.

wangfans

Moreover, GFS has snapshot and record append operations.
Snapshot creates a copy of a file or a directory tree
at low cost. Record append allows multiple clients to append
data to the same file concurrently while guaranteeing
the atomicity of each individual client’s append.

wangfans

It is useful
for implementing multi-way merge results and producerconsumer
queues that many clients can simultaneously append
to without additional locking. We have found these
types of files to be invaluable in building large distributed
applications. Snapshot and record append are discussed further
in Sections 3.4 and 3.3 respectively.

wangfans

2.3 Architecture
A GFS cluster consists of a single master and multiple
chunkservers and is accessed by multiple clients, as shown
in Figure 1. Each of these is typically a commodity Linux
machine running a user-level server process. It is easy to run
both a chunkserver and a client on the same machine, as long
as machine resources permit and the lower reliability caused
by running possibly flaky application code is acceptable.

wangfans

Files are divided into fixed-size chunks. Each chunki s
identified by an immutable and globally unique 64 bit chunk
handle assigned by the master at the time of chunkcreat ion.
Chunkservers store chunks on local disks as Linux files and
read or write chunkda ta specified by a chunkha ndle and
byte range. For reliability, each chunkis replicated on multiple
chunkservers. By default, we store three replicas, though
users can designate different replication levels for different
regions of the file namespace.

wangfans

The master maintains all file system metadata. This includes
the namespace, access control information, the mapping
from files to chunks, and the current locations of chunks.
It also controls system-wide activities such as chunklease
management, garbage collection of orphaned chunks, and
chunkmigration between chunkservers. The master periodically
communicates with each chunkserver in HeartBeat
messages to give it instructions and collect its state.

wangfans

GFS client code linked into each application implements
the file system API and communicates with the master and
chunkservers to read or write data on behalf of the application.
Clients interact with the master for metadata operations,
but all data-bearing communication goes directly to
the chunkservers. We do not provide the POSIX API and
therefore need not hookin to the Linux vnode layer.