Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

The Design Of The Google File System

Posted by timothy on Mon Sep 29, 2003 05:32 PM
from the library-of-babel dept.
Freddles writes "This is an interesting paper (PDF) describing the design approach to Google's file system. The design had to take account of requirements for huge file sizes, a highly responsive infrastructure and an assumption that hardware components will always fail."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by Brahmastra (685988) on Monday September 29 2003, @05:34PM (#7089397)
    Here's the html link [216.109.117.135]
  • by Anonymous Coward on Monday September 29 2003, @05:37PM (#7089412)
    It was thoughtful of the poster to link to google.com for those that have never heard of it.
    • by Queuetue (156269) <{scott} {at} {pantastik.com}> on Monday September 29 2003, @05:40PM (#7089450) Homepage
      Absolutely - I was about to go look google up on teoma and askjeeves...
    • by Anonymous Coward on Monday September 29 2003, @05:48PM (#7089510)
      Last week I had a co-worker ask how to spell it. He is MS cert'd for Win2k Pro. Don't mod this funny, it's sad.
      • Re:Thoughtful... (Score:4, Insightful)

        by xoboots (683791) on Monday September 29 2003, @07:11PM (#7090214) Journal
        There's a reason not every search engine is considered the same. Try a simple search for a popular item. I searched for "PHP" on the three sites you mentioned. The top returned results are as follows:

        Google:
        - top result: php.net
        - 2nd place was php.net/downloads

        AllTheWeb:
        - top result: Hands-On PHP Training - 4 days $1695 (also ranked #10 on Turbo10, but not ranked in the top 20 at Google) -- oops, that is a sponsored link, but in AllTheWeb's default view, it looks like a normal link. php.net is actually ranked #1, but it appears 4th in the list of available links.

        Turbo10:
        - will not provide ANY results without Javascript turned on (BOO!)
        - top result: GBF Masonry Cleaning Services..Stone Cleaning
        - php.net ranked 5

        Draw your own conclusions, but meta-search engines existed prior to Google yet even at its launch it excelled over them in terms of provision of relevant links. It appears that it still does. At least for a first pass :)

        I suspect that one of the reasons that Google can bring higher quality links to the forefront is that being #1, they have a wider and more generous revenue base and therefore don't have to be as generous to "paying patrons" *cough cough*.

        Another problem is that meta engines have to mix "high-quality" results (say from Google) with lower quality results (say from some dippy paid for advertising search engine).
  • by slash-tard (689130) on Monday September 29 2003, @05:37PM (#7089416)
    Google uses MS access as a backend to store all of its cache files. It is redundant by having a batch file setup with the windows "at" command to "xcopy" the data to another backup server.
  • PDF mirror (Score:5, Informative)

    by Tyler Eaves (344284) on Monday September 29 2003, @05:37PM (#7089418)
    PDF mirror on my server [tylereaves.com] /Feels sorry for the Rochester cs server
  • Interesting... (Score:3, Insightful)

    by petermdodge (710869) <[moc.adanac] [ta] [egdodmretep]> on Monday September 29 2003, @05:37PM (#7089421) Homepage
    It's an interesting enough read, it certainly is interesting to see how one of the biggest-volume servers out there cope. Now, the question is, what can us little server guys do to implement the ideas therein to our server? What can we take from it?
    • Now, the question is, what can us little server guys do to implement the ideas therein to our server? What can we take from it?

      Nothing, or you'll be sued for copyright infringement.
  • by Doodhwala (13342) on Monday September 29 2003, @05:38PM (#7089427) Homepage

    Okay, so I read this paper as a part of the SOSP reading group here [cmu.edu] at school [cmu.edu]. Just want to make it clear that this is not the file system used by the front end that we all see. It is used by internal dev groups as well as the web spiders that they employ. Their unique usage has definitely led to a number of interesting choices (such as the atomic appends) for the file system design. Read the paper for more details :-)
    • by Klaruz (734) on Monday September 29 2003, @07:07PM (#7090190)
      Could you cite your source please? In the first page of the paper linked:

      "It is widely deployed within Google for the generation and processing of data used by our service as well as research and development that requires large data sets."
      • by Doodhwala (13342) on Tuesday September 30 2003, @12:21AM (#7091342) Homepage
        And if you read that statement, it does not mention the front-end. Generation and processing all takes place offline as most of the query results are only updated once a month (the Google-dance). And this question was asked of Howard Gobioff (one of the co-authors) at a presentation on the Google File System (GFS) at Carnegie Mellon.
  • Hmmm. (Score:4, Funny)

    by Pig Hogger (10379) <pig.hoggerNO@SPAMgmail.com> on Monday September 29 2003, @05:38PM (#7089434) Homepage Journal
    I'd like to see a beow...
    Never mind.
  • by Anonymous Coward

    Why the google file system is nothing but a waffle iron with a phone attached.
  • Only a file system? (Score:5, Interesting)

    by jrrl (635743) on Monday September 29 2003, @05:39PM (#7089441)
    Back in the early days at Lycos [lycos.com], Danner Stodolsky, now at Akamai [akamai.com] used so many weird little tricks to make things faster that we used to joke that we'd end up with a custom operating system. The supposed name? LycOS.

    Luckily the world was saved from this possibility.

    -John (now, one of those "why, back in my day..." story telling guys... sigh.)

  • by The Ancients (626689) on Monday September 29 2003, @05:39PM (#7089446) Homepage
    I need something for my p...err, book collection.
  • Word processor? (Score:2, Interesting)

    by Anonymous Coward
    What word processor/text editor is used to write all of these technical papers? Almost every paper I've seen looks like it's written in the same program.
    • I think it's FrameMaker.
    • The PDF file claims to have been made by dvips, so it was written in Latex. It was then converted to PDF using Distiller.
    • It's more of a "text compiler" where you concentrate on writing the content and leave all of the formatting to a template that is responsible for transofmring the content into (normally postscript) output. Anybody who has worked with LaTex and then moved to Word, only to have that stupid piece of sh*t bunch all images in a document together, on top of each other, on the first or last page of their document will appreciate the LaTex workflow. And LaTex absolutely rocks when it comes to formulas.

      That being
  • html version (Score:4, Informative)

    by kaan (88626) on Monday September 29 2003, @05:43PM (#7089476)
    thanks to, ehh, Google, here's an html version [216.239.39.104] of the article

    I didn't read the whole article (kinda lengthy) but it seems pretty informative. I found their assumptions interesting, as they reveal some of the essence of what makes Google such a great search tool. Here are a few from the article:

    - The system is built from many inexpensive commodity components that often fail. It must constantly monitor itself and detect, tolerate, and recover promptly from component failures on a routine basis.

    - High sustained bandwidth is more imprtant that low latency. Most of our target applications place a premium onprocessing data in bulk at a high rate, while few have stringent response time requirements for an individual read or write.

    - The workloads primarily consist of two kinds of reads: large streaming reads and small random reads. Successive operations from the same client often read through a contiguous region of a file.
  • by The Ancients (626689) on Monday September 29 2003, @05:47PM (#7089504) Homepage
    ...and an assumption that hardware components will always fail.

    I think perhaps this is something we could all take a little more seriously. Part of me realises this is a comment on the sheer data being manipulated, but then something else that sprung to mind is the gradual reduction of warranties on HDDs, for example. I wonder what sort of stats an operation of this size could gather on various hardware components, and their varying propensities to wither and die.

    • Gradual reduction of hard drive warranties? Didn't Maxtor just bump up the warranty on their drives to 5 years? And WD and Seagate both have 3 year warranties on their drives. Granted, I'm talking about the "good" (SATA, 8 meg cache, etc.) drives, not the cheap ones that most of us users are using rebates to get for really-cheap.
  • Fabulous Insights (Score:5, Informative)

    by dolo666 (195584) on Monday September 29 2003, @05:57PM (#7089570) Journal
    I really enjoyed that read about the file system Google uses. The fact that they usually append to their files, is of special note. By appending data you only need to know a simple pointer address. Seems quick enough. Add a bunch of threaded concurrent writes and you could get into trouble on other systems... The "atomic append" seems interesting because of the use of multiple machines to append simultaneously (hazard free).

    64meg chunk size is pretty huge, but I'm guessing that's blocked out based on continual threads of data, not typical files.

    At first glance, this file system seems fairly wasteful. But hey, Google likely require speed and reliability over cost. Right?

    This reminds me of the discussions about not-so-far-off database filesystems coming to an OS near you.
  • I hope they're going to release it to us mere mortals. I mean, they're probably the only people that need millions of gigabyte+ files floating around thousands of machines, but it would be nice to see

    [ ] Google File System.

    in the kernel config.

    Must be 12pm - the updatedb script it running.

  • by JessLeah (625838) on Monday September 29 2003, @06:01PM (#7089597)
    ...the Linux kernel will have googlefs support. It will be marked (EXPERIMENTAL), though, and will only run on 10,000-node Babelfish clusters...
    • by Anonymous Coward
      Actually this sounds exactly like the sort of file system that would be useful in a render farm.

      How long before ILM or Weta has a GFS disk array?
  • by trick-knee (645386) on Monday September 29 2003, @06:02PM (#7089606) Homepage
    ... which may not have happened from just any company of google's prominence. I mean, they have highly successful business and technical infrastructure models and they didn't HAVE to share it with anyone.

    I wonder what they believe will protect their business from poaching of these ideas?
    • by hankaholic (32239) on Monday September 29 2003, @09:02PM (#7091017)
      I wonder what they believe will protect their business from poaching of these ideas?

      Perhaps the fact that it's taken many very smart people a good amount of time to implement and tune the original design, even after having come up with the basic layout?

      Go take a look at the ReiserFS Future Vision page [namesys.com] -- you'll see some more interesting discussion of filesystem design, and overall direction. There are a few solid developers working full-time on the concepts discussed in the Reiser docs, and they still have enough work to keep them busy for years to come.

      Google releasing information regarding the structure of their systems is a bit like John Carmack discussing the structure of his graphics engines: there's a hell of a distance between a conceptual description and a fine-tuned, tested, working implementation.

      Given Google's history, I'd also imagine that they're on the lookout for up-and-coming young researchers. As such, if some grad student takes their work and extends it, they can certainly benefit.
  • RAIC?? (Score:3, Interesting)

    by More Karma Than God (643953) on Monday September 29 2003, @06:13PM (#7089703)
    Could we call Google a Redundant Array of Inexpensive Computers?

    What else can it be programmed to do? Could this become the basis for a personal computer where you just add computers seamlessly when you need more power?
  • by Skreech (131543) on Monday September 29 2003, @06:21PM (#7089764)
    In case Google gets slashdotted, here is the Google cache [216.239.41.104] for Google.
  • by Epistax (544591) <epistax@@@gmail...com> on Tuesday September 30 2003, @07:41AM (#7092922) Journal
    The question really on all our minds is can you play doom on it?
    • how many times have you searched for something on google, only to find that the search engine spammers have taken over almost every top 10 result?

      Ummm... not very many. Then again, I try not to search on "teen panties" very often. :)

      That reminds me of the winter I spent in Chicago. I needed some galoshes to protect my shoes and keep my feet dry. Back in New England, we called them "rubbers" (I am not making this up). Needless to say, a google search on "buy rubbers" did not yield the intended results.

    • "They could use a more robust file system then. It seems like postings within the past 48 have headers, but google dies when accessing the body."

      Sure! Also, some of the counts of messages per thread are optimistic. I guess they've been told 1000 times already..or maybe I should mail them about it too?