Notes from the 10/10 discussion on the "The Google File System" paper.

Zachary Peterson

- In general, Google identifies real problems that exists in their
system, and has designed and implemented a system that is
specific solution to these problems.
- Built on commodity hardware, the Google engineers solved many fault
tolerance and specific application needs: such as concurrent writing,
replica sharing, and system snapshot.
- The designers identify trade-offs for their design; choosing
high-bandwidth over low-latency.
- The techniques used were not novel, nor did this paper introduce a
wildly new architecture.  It was a good practice and experience paper, but
failed to cite many of related and seminal works in the field.
- The most harsh criticism came from the lack of comparative experimental
results, or results that really demonstrated that the needs of the
applications were being met.

Delayed notes from Andreas

Good Points:
-I really liked their philosophy "anything can fail" and "failures is the norm rather than the
exception". Making this assumption forces the design towards a direction where the minimum number of assumptions are made and the simplest mechanisms are always picked (so that complex failure scenarios will not emerge)
-I also like that they built the whole thing on top of PCs running Linux

Questions:

-It would be nice to know what's the cost of this system in comparison to a system not built from PCs and Ethernet switches

-It would also be nice to know whether this filesystem would also be applicable to other applications or whether it's really customized for their own set of applications. For example, it seems that if many small files are created then the single master might become a bottleneck since the creation of many files would lead to an increased log which would then have to be frequently checkpointed to the disk.

-Along the same lines, it would be nice to know what's the relative performance of GFS compared to some of the other distributed file systems they mention

-I am also wondering whether the fact that the whole filesystem is built on top of ext2fs can actually cause some problems. For example, when the master copies the checkpoint to the filesystem, is it possible that the write actually stays in the Linux buffer cache and doesn't make it to the disk before the machine crashes? Is there a way to bypass the buffer cache and write straight to disk? In general, would it be safer, faster to build this on top of raw disk?