块尺寸是关键设计参数之一。我们选择了64MB，这远大于一般文件系统的块尺寸。每个块副本保存在块服务器上的Linux文件内，尺寸只在需要的时候才扩展变大。惰性空间分配避免了造成内部碎片带来的空间浪费，或许对巨大的块尺寸最没有争议的就是这点。
巨大的块尺寸有几个重要的好处。首先，它减少了客户端和主服务器通讯的需求，因为对同一个块的读写，只需要一次用于获得块位置信息的与主服务器的通讯。对我们的工作负载来说，这种减少尤其明显，因为我们的应用程序经常连续读写巨大的文件。即使是对小规模随机读取也有好处，因为客户端也可以轻松的缓存一个数TB工具集的所有块位置。其次，由于块尺寸很大，所以客户端会对一个给定的块进行许多操作，这样就可以通过跟块服务器保持较长时间的TCP连接来减少网络负载。第三，它降低了主服务器需要保存的元数据的尺寸。这就允许我们把元数据放在内存中，这样会带来一些其他的好处，我们将在2.6.1章节讨论。
另一方面，巨大的块尺寸，即使配合惰性空间分配，也有它的缺点。小文件包含较少的块，甚至可能是一块。如果有许多的客户端访问同一个小文件，那么存储这些块的块服务器就会变成热点。在实践中，热点没有成为主要的问题，因为我们的程序通常是连续的读取多个块的大文件。
然而，在GPS第一次用于一个批处理队列系统的时候，热点还是产生了：一个执行文件被写为GFS的一个单块文件，然后在数百个机器上同时启动。保存这个执行文件的几个块服务器被数百个并发请求访问到过载的地步。我们解决了这个问题，方法是用更高的复制参数来保存这类的执行文件，以及让批处理队列系统错开程序的启动时间。一个可能的长期解决方案是，在这样的情况下，允许客户端从其他客户端读取数据。（译者注：这个热点事件，其实就是一个典型的文件分发问题，而后面提到的所谓可能的长期解决方案其实就是p2p。）