64KB 在磁盘 IO 方面有什么意义，这与 JavaScript 相关吗？
What is the significance of 64KB in terms of disc IO and is this relevant in JavaScript?
我正在查看通过生成器读取大型平面文件的 node.js library (gen-readlines) - 即通过生成器一次读取 'chunks' 65 536 字节的文件。
我没有 CS 背景，直到有人提到磁盘一次读取 65 536 字节的数据之前，我并没有想太多。
问题：
- 所有磁盘（金属和 SSD）都是这样吗？
- 8 字节 == 64 位。 64 位处理器与 64 位 * 1024 字节读取大小的磁盘读取之间有什么关系？
- 即64KB 对磁盘 IO 有什么意义？
- 考虑到 JavaScript 有多高级，我真的可以在读取一张光盘后指示生成器
yield 字节吗？或者在 JavaScript... 方面考虑时，我链接到的库中指定为缓冲区大小的数字是完全任意的
虽然磁盘读取可能是对齐的，但 OS 使其大部分透明；正如您提到的那样您正在按顺序阅读，您使用的缓冲区大小并不重要。 64位和64KB对齐没有关系（反正我只听说过4K对齐）
您可能想要创建一个大小为 2 的幂的缓冲区；只是为了更好地与内存分配器对齐。 JavaScript 抽象了大部分内存分配，因此当您有 64K 或 4K 缓冲区时，它没有必要提高性能（在正常意义上，它应该足够大以减少系统调用开销）。
以您喜欢的方式执行 IO，只要有缓冲即可。缓冲区大小无论是 4K 还是 64K 都没有太大关系（但是太小的缓冲区不好，因为没有缓冲），但是 IO 是否有缓冲，非常重要。
Is this true of all disks (both metallic and SSD)?
不，这取决于磁盘的格式化方式，cluster 大小 IIRC。它在当今世界是一个相当普遍的值，但较小的簇大小并不 un 常见。它们通常是 4k 的倍数（过去十年或更长时间）。小时候，世界是新的，512字节很正常。 :-) 64k 可能足够大，即使是格式化为大簇大小的磁盘。
但是它比磁盘分配的基本单位要多得多。一方面，很可能存在多级缓存——在磁盘驱动器的内置控制器中，在主板上的磁盘控制器中，在 OS... 今天的磁盘（甚至昨天的，或前天的） ) 不是愚蠢的拼盘，我们必须尝试用代码进行微观管理。
8 bytes == 64 bit. What is the relationship between a 64 bit processor and a disk read of 64bits * 1024 bytes read sizes?
除此之外它们都是 2 的幂，我认为没有。
Considering how high-level JavaScript is, can I really instruct a generator to yield bytes after exactly one disc read?
这不是真正的关键问题。关键问题是代码 in 生成器函数（或任何函数）是否可以一次准确读取 64k。
答案是肯定的，代码确实如此：
let bytesRead = fs.readSync(fd, readChunk, 0, bufferSize, position);
...其中 bufferSize 是 64k。 readSync为低级调用
总结：64k 可能足以容纳磁盘的最大最小分配单元；如果它太大，没问题，它仍然不是离谱的，可以将多个分配单元读入其中。但在我相信它产生重大影响之前，我希望看到精心设计的基准。我可以看到其中的逻辑，但是甚至 readSync 内部的 Node 的 C++ 代码和磁盘的实际物理读取之间的层...
1- 不，这取决于存储设备的固件、驱动器控制器和操作系统。较新的 HDD 使用 4 KiB 扇区，因此这样的磁盘一次至少读取 4 KiB。
2- 处理器的寄存器或总线大小与磁盘 I/O 块之间没有关系。
3- 数据速率取决于数据大小和 I/O 延迟开销（由于 I/O 处理引起的开销，例如系统调用处理）。对于相同的数据大小，更大的数据块意味着更少 I/O，意味着更少的 I/O 开销。
4-从JavaScript高层的角度来看，你不需要担心这些底层行为。一切都会正常工作，因为有多个级别的许多缓存。
我正在查看通过生成器读取大型平面文件的 node.js library (gen-readlines) - 即通过生成器一次读取 'chunks' 65 536 字节的文件。
我没有 CS 背景，直到有人提到磁盘一次读取 65 536 字节的数据之前，我并没有想太多。
问题：
- 所有磁盘（金属和 SSD）都是这样吗？
- 8 字节 == 64 位。 64 位处理器与 64 位 * 1024 字节读取大小的磁盘读取之间有什么关系？
- 即64KB 对磁盘 IO 有什么意义？
- 考虑到 JavaScript 有多高级，我真的可以在读取一张光盘后指示生成器
yield字节吗？或者在 JavaScript... 方面考虑时，我链接到的库中指定为缓冲区大小的数字是完全任意的
虽然磁盘读取可能是对齐的，但 OS 使其大部分透明；正如您提到的那样您正在按顺序阅读，您使用的缓冲区大小并不重要。 64位和64KB对齐没有关系（反正我只听说过4K对齐）
您可能想要创建一个大小为 2 的幂的缓冲区；只是为了更好地与内存分配器对齐。 JavaScript 抽象了大部分内存分配，因此当您有 64K 或 4K 缓冲区时，它没有必要提高性能（在正常意义上，它应该足够大以减少系统调用开销）。
以您喜欢的方式执行 IO，只要有缓冲即可。缓冲区大小无论是 4K 还是 64K 都没有太大关系（但是太小的缓冲区不好，因为没有缓冲），但是 IO 是否有缓冲，非常重要。
Is this true of all disks (both metallic and SSD)?
不，这取决于磁盘的格式化方式，cluster 大小 IIRC。它在当今世界是一个相当普遍的值，但较小的簇大小并不 un 常见。它们通常是 4k 的倍数（过去十年或更长时间）。小时候，世界是新的，512字节很正常。 :-) 64k 可能足够大，即使是格式化为大簇大小的磁盘。
但是它比磁盘分配的基本单位要多得多。一方面，很可能存在多级缓存——在磁盘驱动器的内置控制器中，在主板上的磁盘控制器中，在 OS... 今天的磁盘（甚至昨天的，或前天的） ) 不是愚蠢的拼盘，我们必须尝试用代码进行微观管理。
8 bytes == 64 bit. What is the relationship between a 64 bit processor and a disk read of 64bits * 1024 bytes read sizes?
除此之外它们都是 2 的幂，我认为没有。
Considering how high-level JavaScript is, can I really instruct a generator to yield bytes after exactly one disc read?
这不是真正的关键问题。关键问题是代码 in 生成器函数（或任何函数）是否可以一次准确读取 64k。
答案是肯定的，代码确实如此：
let bytesRead = fs.readSync(fd, readChunk, 0, bufferSize, position);
...其中 bufferSize 是 64k。 readSync为低级调用
总结：64k 可能足以容纳磁盘的最大最小分配单元；如果它太大，没问题，它仍然不是离谱的，可以将多个分配单元读入其中。但在我相信它产生重大影响之前，我希望看到精心设计的基准。我可以看到其中的逻辑，但是甚至 readSync 内部的 Node 的 C++ 代码和磁盘的实际物理读取之间的层...
1- 不，这取决于存储设备的固件、驱动器控制器和操作系统。较新的 HDD 使用 4 KiB 扇区，因此这样的磁盘一次至少读取 4 KiB。
2- 处理器的寄存器或总线大小与磁盘 I/O 块之间没有关系。
3- 数据速率取决于数据大小和 I/O 延迟开销（由于 I/O 处理引起的开销，例如系统调用处理）。对于相同的数据大小，更大的数据块意味着更少 I/O，意味着更少的 I/O 开销。
4-从JavaScript高层的角度来看，你不需要担心这些底层行为。一切都会正常工作，因为有多个级别的许多缓存。