基于GFS的应用程序利用一些其他目的也需要的简单技术就可以跟简化的一致性模型协作了：倚靠追加而不是其他的写入，检查点，写操作的自验证，自说明的记录。
实际上，我们所有的程序对文件的操作追加比覆盖多。一种典型的使用情况是，写入者从头到尾生成了一个文件。写入所有数据后写入者把文件名改为一个持久的文件名，或者周期性的检查成功写入了多少数据。检查点可以包含程序级别的校验和。读取者仅验证并处理上个检查点内的文件区域，这些文件区域的状态一定是已定义的。这个方法满足了我们所有的一致性和并行性的要求。追加比随机位置写入更加有效率，而且对应用程序的失败更有弹性。检查点可以让写入者渐进的重新开始，并且可以保证读取者处理已经被成功写入的文件数据，即使从应用程序的观点来看文件的写入并未完成。
另外一种典型的使用情况下，许多写入者并行的追加数据到同一个文件，进行结果的合并或者进行生产者-消费者模型队列。记录追加的至少一次追加的语意保证了每个写入者的输出。读取者用下面的方法来处理偶然填充数据和重复内容。写入者准备的每条记录都包含了额外的信息，例如校验和，可以用来验证它的有效性。读取者可以利用校验和抛弃额外的填充数据和记录片段。如果应用不能容忍偶尔的重复内容(比如，如果他们想触发非幂等操作)，可以用记录的唯一标识符来过滤它们，这些唯一标识符通常用于命名相应的程序节点，例如web文档。这些记录I/O的功能都包含在库代码中在我们的程序中共享，并且适用于Google实现的其他的文件接口。所以，相同系列的记录，加上一些罕见的重复，总是直接被分发给记录读取者。