我们什么时候应该使用分散/聚集（向量）IO？
Windows file system supports scatter/gather IO.(Of course, other platform does)
But I don't know when do I use the IO mechanism.
Could you explain me a proper case?
And what benefit can we get from using the I/O mechanism?(Just a little IO request?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
当您进行大量随机（即非顺序）读取/写入，并且希望节省上下文切换/系统调用时，您可以使用分散/收集 IO - 从这个意义上说，分散/收集是批处理的一种形式。但是，除非您有一个非常快的磁盘（或更可能是一个大型磁盘阵列），否则系统调用成本可以忽略不计。
如果您正在编写数据库服务器，您可能会关心这一点，但是除了每秒处理数千或数百万个请求的大型机器之外，任何其他东西都看不到任何好处。
You use Scatter/Gather IO when you are doing lots of random (i.e. non-sequential) reads / writes, and you want to save on context switches / syscalls - Scatter/Gather is a form of batching in this sense. However, unless you've got a very fast disk (or more likely, a large array of disks), the syscall cost is negligible.
If you were writing a Database server, you might care about this, but anything less than a big-iron machine handling thousands or millions of requests a second won't see any benefit.
Paul - 一个额外的说明：另一个优点是您可以同时向磁盘驱动程序发送多个请求。然后，驱动程序可以对请求进行排序并以最佳顺序发出它们。虽然系统调用时间很短，但寻道时间（许多毫秒）可能是惩罚性的（小于 1000 个 I/O/秒）。
克里斯关于展示效率的评论是务实的。大自然从不说谎。嗯，几乎从来没有。
Paul -- one extra note: one additional advantage is that you hand multiple requests to the disk driver at the same time. The driver then can sort the requests and issue them in the optimal order. While syscall time is small, seek time (many milliseconds) can be punitive (that's less than 1000 I/O's/sec).
Chris's comment about demonstrating the efficiency is pragmatic. Mother nature never lies. Well, almost never.
我可以想象，当您 (a) 怀疑您的应用程序存在性能瓶颈，并且 (b) 您构建了一个性能分析框架，可以显示使用它的显着改进时，您会使用 scatter gatewayhr IO。
除非您能够展示出可证明的改进，否则额外的代码复杂性只是一种风险，并且没有什么神奇的方法可以证明，当满足某些条件时，应用程序将自动从某些编程技巧中获得显着的好处。
或者 - 换句话说 - 不要根据“互联网论坛上某个人”的声明来制定主要的架构决策。创建一个测试并找出答案。
I would imagine that you would use scatter gatehr IO when you (a) suspected your application had a performance bottleneck, and (b) you built a performance analysis framework that could show significant improvment using it.
Unless you can show a provable improvement, the additional code complexity is just a risk, and theres no magic recipe that says that, when some condition is met, and application will automatically benefit in a significant way from some programming cleverness.
Or - to put it another way - dont base major architectural decisions based on the statements of 'some guy on an internet forum'. Create a test, and find out.
在 posix 中，readv 和 writev 从不连续内存中读取或写入，但是要一次性从不连续内存中读取和写入不连续文件范围，您需要 readx 和 writex，它们是建议的 posix 添加之一，
执行 readx 比执行大量操作更快读起来，因为它只是一个系统调用，它让磁盘调度程序有最多的 io 来重新排序我记得有人说过，对于 ext2/3/.. fsck 程序，他们想要这个，因为它知道它想要什么范围
in posix, readv and writev read from or write to discontinuous memory but to read and write discontinuous file ranges from discontinuous memory in one go you want readx and writex which were one of the proposed posix additions
doing a readx is faster then doing a lot of reads as it's only one system call and it lets the disk scheduler have the most io's to reorder i remember some one saying that for the ext2/3/.. fsck program that they wanted this as it knows what ranges it wants