有效使用16KB物理块大小
Google Compute Engine可以选择使用16KB物理块大小及其永久磁盘而不是默认的4KB。除了本页顶部附近的内容基本上没有任何文档说明它存在。我试图弄清楚文件系统和底层硬件（或SAN）如何处理这个设置，以实现最大的顺序读/写吞吐量。
我的理解是物理块大小应该匹配（或不大于）逻辑（文件系统）块大小; 物理大于逻辑（ref）是没有意义的。创建更大的逻辑块似乎很困难：
- EXT4支持1024,2048和4096。
- XFS最多支持64 KiB，但要求块大小不大于页面大小（4K）。
- btrfs听起来如果它的扇区大小（相当于块大小？）与页面大小不匹配则无法挂载。
- ZFS我不是很熟悉，但听起来很有希望。本文说所有文件都存储为不同大小的单个块（最多为recordsize）或使用多个recordsize块。一旦文件增长为多个块，如果当时明确设置为FS记录大小，则为块大小。维基百科还表示它可以使用可变块大小。
我可以并且将进行基准测试，但是使用ZFS的默认128KB记录大小和一个16KB块大小的磁盘可以提供比4KB块大小更高的顺序吞吐量吗？我不是在寻找一个广泛的“x比y快”的说法; 我对更大的物理块大小如何更快以及如何有效地使用它的技术基础感兴趣。这适用于高度调整的HPC应用程序，即使是很小的改进也能从中受益。
我确实发现这个GCE教程解释了16K块提供16K原子写入，消除了对应用程序级双写的需要，从而释放了带宽，但我不确定这是否是更大的物理块可以提供帮助的唯一方法。
（为了增加我的困惑，GCP的博客文章块大小对永久磁盘性能的影响显示了使用fio制作的块大小从4k到1M的图表。它们没有显示用于制作该图表的代码，但我认为这是完全不相关 - 我假设他们使用-bsfio 的标志来调整发出的读/写的大小。）
回答 1
Stack Overflow用户
发布于 2019-06-24 09:49:48
不要更改块大小。4 KB是每个人（软件供应商/驱动程序等）测试的标准。如果这样做，请使用64 KB，这是另一种常见标准（约定）。
除了物理连接的磁盘驱动器之外，目前没有改进块大小的性能优势。对于通过SAN连接的磁盘，有太多其他因素可以控制性能。您的VM的磁盘驱动器视图已被抽象出来。您的磁盘实际上只是区域中其他位置的阵列中许多磁盘的子集。网络性能将成为主导因素。接下来是用于缓存文件系统的OS内存。
块大小确实会影响从OS到应用程序的内存传输速度。然而，今天的CPU速度如此之快，内存速度如此之高，以至于您将面临挑战，证明任何块大小都会产生差异（除了小于4 KB）。
https://stackoverflow.com/questions/-100007037
复制相似问题