The Google File System
ACM SIGOPS Operating Systems Review, 2003 · paper · Computer science
Describes the Google File System, a scalable distributed file system running on inexpensive commodity hardware for data-intensive applications. Reports that it meets Google's storage needs, with clusters of hundreds of terabytes serving hundreds of clients.
Checked: PDF from static.googleusercontent.com, fetched 4 Oct 2026. Page numbers are those of that PDF.
2 findings
Substance Section 6.3.3 gives "the ratio of writes to record appends is 108:1 by bytes transferred and 8:1 by operation counts" (3.7:1 and 2.5:1 for Y), then concludes "these ratios suggest that for both clusters record appends tend to be larger than writes". As printed, the ratios make the average write larger than the average record append in both clusters.
- p. 13 Section 6.3.3, Appends versus Writes
these ra-tios suggest that for both clusters record appends tend to be larger than writes
- p. 13 Section 6.3.3
the ratio of writes to record appends is 108:1 by bytes transferred and 8:1 by operation counts
Only the authors can say what is right here.
Judge's note: Mean write size divided by mean record-append size equals the bytes ratio divided by the operations ratio: 13.5 for X and about 1.48 for Y. Both are above 1, so the stated ratios contradict the conclusion drawn from them. Reading the ratios the other way round does not help: the same paragraph says record-append usage in X was 'fairly low', which matches writes dominating by bytes. For cluster X, Table 4 also puts record-append operations mostly at 8K..64K (78.0%), while writes cluster at 128K..1M. Either the ratios or the conclusion is wrong, and only the authors can say which.
Second check: another model agreed
Report a problem with this finding
Substance Table 5, Record Append column for cluster X (<.1, <.1, 2.3, 22.7, <.1, <.1, .1, 53.9) sums to about 79%, not 100%.
- p. 13 Table 5, Record Append column X, row 512K..1M
.1
- p. 13 Table 5, Record Append X column, 1M..inf row
53.9
Only the authors can say what is right here.
Judge's note: Values read from the page 13 crop. The other five columns of Table 5 sum to 100.0, 100.0, 100.0, 100.1 and 100.0. The four '<.1' cells add at most 0.4, so the column is at most about 79.4%. There is no footnote explaining missing categories. The bare '.1' in row 512K..1M is a likely suspect, but only the authors can say which cell is wrong.
Second check: another model agreed
Report a problem with this finding
15 minor (typos and the like; most checked by the judge only)
Reference or label Reference [3] gives the venue of the Swift paper as "Computer Systems, 4(4):405–436, 1991"; the journal is apparently 'Computing Systems'.
- p. 15 Reference [3]
Computer Systems, 4(4):405–436, 1991
Only the authors can say what is right here.
Judge's note: Rests on outside knowledge: that Cabrera and Long's Swift paper appeared in the USENIX journal 'Computing Systems', 4(4). The crop of page 15 shows the italic venue as 'Computer Systems'. Nothing in the files settles the real journal name, so the authors should confirm it.
Second check: another model agreed
Report a problem with this finding
Wording Section 6.2.2 says "Each individual server, both chunkservers and the master, has only 50 to 100 MB of metadata", but by Table 2 cluster A averages 13 GB/342 ≈ 38 MB per chunkserver and its master holds 48 MB.
- p. 11 Section 6.2.2, last paragraph
has only 50 to 100 MB of metadata
- p. 11 Table 2
13 GB
Only the authors can say what is right here.
Judge's note: Table 2 (page 11 image) gives 13 GB of chunkserver metadata over 342 chunkservers and 48 MB at the master for A, and 21 GB over 227 chunkservers and 60 MB for B. Cluster A's per-chunkserver average is clearly below the stated lower bound, and its master is just below it. The range is probably meant as a rough figure, so this reads as an overstatement rather than a wrong number.
Second check: another model agreed
Report a problem with this finding
Wording Table 2 is never cited by number; Section 6.2.1 refers to it only as "As shown by the first five entries in the table".
- p. 11 Section 6.2.1
As shown by the first five entries in the table
Judge's note: A search of the text finds 'Table 2' only in its caption. Every other table is cited by number. The table sits right above Section 6.2.1, so the reference can be resolved, which makes this minor.
Second check: another model agreed
Report a problem with this finding
Wording Table 4, Record Append column for cluster Y (0, 9.2, 15.2, 2.8, 4.3, 10.6, 31.2, 25.5, 2.2) sums to 101.0%.
- p. 13 Table 4, Record Append column Y
31.2
- p. 13 Table 4, Record Append, cluster Y
9.2 15.2 2.8 4.3 10.6 31.2 25.5 2.2
Only the authors can say what is right here.
Judge's note: Values read from the page 13 crop. The other Table 4 columns sum to 99.9 to 100.1. The excess of 1.0 is more than rounding eight nonzero one-decimal entries can produce (at most about 0.4). It is small, but some cell appears misprinted.
Second check: another model agreed
Report a problem with this finding
Typo The ACM subject descriptor is garbled as printed: "D [4]: 3—Distributed file systems".
- p. 1 Categories and Subject Descriptors
D [4]: 3—Distributed file systems
Judge's note: In the page 1 crop the descriptor reads 'D [4]: 3—Distributed file systems', with a bold 4 in brackets and no category names, so the defect is in the PDF and not an extraction artefact. The likely intended form, D.4.3 [Operating Systems]: File Systems Management, comes from the ACM classification, which is not in the files.
Second check: none (judge only)
Report a problem with this finding
Typo Section 2.6.1 reads "the file namespace data typically requires less then 64 bytes per file", where "than" is meant.
- p. 4 Section 2.6.1
requires less then 64 bytes per file
- p. 4 Section 2.6.1, second paragraph
requires less then
- p. 4 2.6.1
typically requires less then
- p. 4 2.6.1
typically requires less then 64 bytes per file
Judge's note: Page 4 crop confirms 'less then 64 bytes per file'. The same paragraph uses 'less than 64 bytes' correctly a few lines earlier. The other slips some reviewers bundled in here ('Gobal', 'lustreorg', 'Brain Bershad') are on page 15 and are judged under C015.
Second check: none (judge only)
Report a problem with this finding
Typo Section 3.2 reads "S1 for-wards it to the closest chunkserver S2 through S4 closest to S1, say S2", with 'closest' used twice in one clause.
- p. 6 Section 3.2, third paragraph
S1 for-wards it to the closest chunkserver S2 through S4 closest to S1, say S2.
Judge's note: Page 6 image, Section 3.2, third paragraph, shows the doubled 'closest'. The next sentence ('whichever is closer to S2') shows that only one was intended. The meaning is still clear, so this is cosmetic.
Second check: none (judge only)
Report a problem with this finding
Typo Section 3.3 reads "to all replicas of the last chunk of the file Then, it sends its request", with no full stop after 'file'.
- p. 7 Section 3.3, second paragraph
last chunk of the file Then, it sends its request
- p. 7 Section 3.3, second paragraph
last chunk of the file Then, it sends
Judge's note: Page 7 crop confirms there is no period between 'file' and 'Then'.
Second check: none (judge only)
Report a problem with this finding
Typo Section 4.1 prints "(i.e, hard or symbolic links in Unix terms)"; the abbreviation lacks its second period.
- p. 7 Section 4.1, second paragraph
(i.e, hard or symbolic links in Unix terms)
Judge's note: Page 7 crop confirms 'i.e,'. Elsewhere the paper writes 'i.e.,' (Section 3.3, page 6).
Second check: none (judge only)
Report a problem with this finding
Typo Section 6.2.1 reads "files which were deleted or replaced by a new version but whose storage have not yet been reclaimed"; the verb should agree with the singular 'storage' ('has').
- p. 11 6.2.1
whose storage have not yet been reclaimed
Judge's note: Page 11 crop confirms the wording. It is a grammatical slip only.
Second check: none (judge only)
Report a problem with this finding
Typo Section 6.3.4 names the request type "(FindLease-Locker)", but Table 6 lists it as "FindLeaseHolder".
- p. 13 Section 6.3.4
(FindLease-Locker)
- p. 13 Table 6
FindLeaseHolder
- p. 13 6.3.4 Master Workload
(FindLease-Locker) for data mutations
- p. 13 Section 6.3.4
FindLease-
Judge's note: Page 13 crop shows 'FindLease-' at the line end and 'Locker' on the next line, so this is not a hyphenation artefact. The text describes it as 'lease holder information', which matches the FindLeaseHolder row of Table 6.
Second check: none (judge only)
Report a problem with this finding
Typo Page 15 has three typographical slips: reference [11] title "The Gobal File System", reference [8] URL "http://www.lustreorg" with no dot before 'org', and "Brain Bershad (our shepherd)" in the Acknowledgments.
- p. 15 Reference [11]
The Gobal File System
- p. 15 Ref [8]
http://www.lustreorg
- p. 15 Acknowledgments
Brain Bershad
Only the authors can say what is right here.
Judge's note: Rests on outside knowledge: that the cited title is 'The Global File System', that the shepherd's first name is Brian, and that the Lustre site is www.lustre.org. All three strings appear exactly as quoted in the page 15 image. 'Gobal' is supported by the paper's own text, which calls this system 'Minnesota's GFS'.
Second check: none (judge only)
Report a problem with this finding
Typo Reference [8] gives the URL as "Lustre. http://www.lustreorg, 2003." There is no dot before 'org' (should be www.lustre.org).
- p. 15 Reference [8]
http://www.lustreorg
- p. 15
http://www.lustreorg, 2003.
Judge's note: I checked the crop of PDF page 15. The URL is printed as 'www.lustreorg' with no dot, so this is not an extraction artefact. In the same list, [6] prints 'www.inter-mezzo.org' with the dot, which shows the intended form.
Second check: none (judge only)
Report a problem with this finding
Typo The Acknowledgments print "Brain Bershad (our shepherd)"; the first name is apparently misspelled for 'Brian'.
- p. 15 Acknowledgments
Brain Bershad (our shepherd)
Only the authors can say what is right here.
Judge's note: Rests on outside knowledge: that the shepherd's name is Brian Bershad. The crop of page 15 does show 'Brain Bershad'. It reads as a transposition typo, but the correct spelling is not stated anywhere in the files.
Second check: none (judge only)
Report a problem with this finding
Typo Section 9 reads "by chunk leases, which delegates authority to primary replicas"; the plural antecedent needs 'delegate'.
- p. 15 Section 9, third paragraph
by chunk leases, which delegates authority
Judge's note: I checked the crop of page 15 and the text is as quoted. The relative clause describes what the leases do, so its verb should agree with the plural 'chunk leases'. This is a minor grammatical slip.
Second check: none (judge only)