我要确保我正确理解这个概念：
在hadoop的明确指南中，它指出：“设计文件系统的目标总是减少查找次数，而不是要传输的数据量。”在这句话中，作者指的是hadoop逻辑块的“seeks（）”，对吗？
我认为，无论hadoop块大小有多大（64mb或128mb或更大），底层文件系统（例如ext3/fat）必须执行的物理块（通常为4kb或8kb）的寻道数将是相同的，无论hadoop块大小如何。
示例：为了简化数字，假设底层文件系统块大小为1mb。我们要读取一个128mb大小的文件。如果hadoop块大小为64mb，则该文件占用2个块。阅读时有128次搜索。如果hadoop块大小增加到128mb，文件系统执行的寻道数仍然是128。在第二种情况下，hadoop将执行1个seek而不是2个seek。
我的理解正确吗？
如果我是对的，通过增加块大小来显著提高性能只会出现在非常大的文件中，对吗？我在想，对于大小在1 gb范围内的文件，将寻道次数从20次寻道（64mb块大小）减少到10次寻道（128mb块大小）应该没有多大区别，对吧？
1条答案
按热度按时间n53p2ov01#
增加文件系统块大小将提高性能，这是正确的。linux要求块大小小于或等于页面大小。x86页面大小限制为4k；因此，即使文件系统可以支持更大的块大小，也可以使用4k的最大块大小。大数据块大小和页面大小的性能优势是显著的：读/写系统调用的减少，旋转延迟和寻道的减少（不要开始考虑ssd），更少的上下文切换，改进的缓存局部性，更少的tlb未命中，等等。这都是优点。
我根据磁盘使用模式分析了各种块大小的好处，在某些情况下还预测了磁盘子系统的数量级改进。这将把性能瓶颈转移到其他地方。
你说得对，有可能获得实质性的性能提升。不幸的是，控制这些改进的某个工程师认为大于4k的页面大小没有任何价值。他嘲笑那些需要高性能的企业用户，他们在big iron上的工作负载基本上是同质的，并关注在台式机或笔记本电脑系统上交互运行的异构工作负载，而在这些系统中，高性能并不重要。