Google File System

Google File System (GFS) is a proprietary distributed file system developed by Google for its own use. "Despite having published details on technologies like the Google File System, Google has not released the software as open source and shows little interest in selling it. The only way it is available to another enterprise is in embedded form--if you buy a high-end version of the Google Search Appliance, one that is delivered as a rack of servers, you get Google's technology for managing that cluster as part of the package." [http://www.baselinemag.com/article2/0,1540,1985050,00.asp "How Google Works"] ] It is designed to provide efficient, reliable access to data using large clusters of commodity hardware.

Design

GFS is optimized for Google's core data storage and usage needs (primarily the search engine), which can generate enormous amounts of data that need to be retained;"All this analysis requires a lot of storage. Even back at Stanford, the Web document repository alone was up to 148 gigabytes, reduced to 54 gigabytes through file compression, and the total storage required, including the indexes and link database, was about 109 gigabytes. That may not sound like much today, when you can buy a Dell laptop with a 120-gigabyte hard drive, but in the late 1990s commodity PC hard drives maxed out at about 10 gigabytes." [http://www.baselinemag.com/article2/0,1540,1985046,00.asp "How Google Works"] .] Google File System grew out of an earlier Google effort, "BigFiles", developed by Larry Page and Sergey Brin in the early days of Google, while it was still located in Stanford."To cope with these demands, Page and Brin developed a virtual file system that treated the hard drives on multiple computers as one big pool of storage. They called it BigFiles. Rather than save a file to a particular computer, they would save it to BigFiles, which in turn would locate an available chunk of disk space on one of the computers in the server cluster and give the file to that computer to store, while keeping track of which files were stored on which computer. This was the start of what essentially became a distributed computing software infrastructure that runs on top of Linux." [http://www.baselinemag.com/article2/0,1540,1985046,00.asp "How Google Works"] ] Files are divided into chunks of 64 megabytes, which are only extremely rarely overwritten, or shrunk; files are usually appended to or read. It is also designed and optimized to run on Google's computing clusters, the nodes of which consist of cheap, "commodity" computers, which means precautions must be taken against the high failure rate of individual nodes and the subsequent data loss. Other design decisions select for high data throughputs, even when it comes at the cost of latency.

The nodes are divided into two types: one "Master" node and a large number of "Chunkservers". Chunkservers store the data files, with each individual file broken up into fixed size chunks (hence the name) of about 64 megabytes,"The files managed by the system typically range from 100 megabytes to several gigabytes. So, to manage disk space efficiently, the GFS organizes data into 64-megabyte "chunks," which are roughly analogous to the "blocks" on a conventional file system--the smallest unit of data the system is designed to support. For comparison, a typical Linux block size is 4,096 bytes. It's the difference between making each block big enough to store a few pages of text, versus several fat shelves full of books." [http://www.baselinemag.com/article2/0,1540,1985047,00.asp "How Google Works"] ] similar to clusters or sectors in regular file systems. Each chunk is assigned a unique 64-bit label, and logical mappings of files to constituent chunks are maintained. Each chunk is replicated several times throughout the network, with the minimum being three, but even more for files that have high demand or need more redundancy.

The Master server doesn't usually store the actual chunks, but rather all the metadata associated with the chunks, such as the tables mapping the 64-bit labels to chunk locations and the files they make up, the locations of the copies of the chunks, what processes are reading or writing to a particular chunk, or taking a "snapshot" of the chunk pursuant to replicating it (usually at the instigation of the Master server, when, due to node failures, the number of copies of a chunk has fallen beneath the set number). All this metadata is kept current by the Master server periodically receiving updates from each chunk server ("Heart-beat messages").

Permissions for modifications are handled by a system of time-limited, expiring "leases", where the Master server grants permission to a process for a finite period of time during which no other process will be granted permission by the Master server to modify the chunk. The modified chunkserver, which is always the primary chunk holder, then propagates the changes to the chunkservers with the backup copies. The changes are not saved until all chunkservers acknowledge, thus guaranteeing the completion and atomicity of the operation.

Programs access the chunks by first querying the Master server for the locations of the desired chunks; if the chunks are not being operated on (if there are no outstanding leases), the Master replies with the locations, and the program then contacts and receives the data from the chunkserver directly (similar to Kazaa and its supernodes).

As opposed to many filesystems, GFS is not implemented in the kernel of an operating system, but is instead provided as a userspace library.

ee also

*BigTable
*MapReduce
*Fossil, the native file system of Plan 9
*List of Google products
*Hadoop and its "Hadoop Distributed File System" (HDFS), an open source Java product similar to GFS.
* Cloud storage

References

* [http://labs.google.com/papers/gfs.html "The Google File System"] ( [http://labs.google.com/papers/gfs-sosp2003.pdf PDF] ), Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung; pub. 19th ACM Symposium on Operating Systems Principles, Lake George, NY, October, 2003.

External links

* [http://labs.google.com/papers/gfs.html A Google published research paper about GFS]
* [http://storagemojo.com/?page_id=152 Google File System Eval: Part I] at [http://storagemojo.com/ StorageMojo]
* [http://www.baselinemag.com/article2/0,1540,1985047,00.asp "How Google Works"]
* [http://news.zdnet.com/2100-9588_22-5596811.html ZDnet article on GFS]