同时有两个进程 A 、B，每个进程都打开不同的文件。A 进程进行追加写入，这种情况下，调度到 B 进程后，B 读写 fd，需要转动磁盘。美国服务器再次调度回到 A 进程，还是要再次转动磁盘，这不就是相当没有起到追加写的作用吗？

不知道楼主在说什么，我猜可能是指 A 进程的追加写入没达到楼主的性能预期？

是的。楼主想法没错。所以一般这里会采取 mmap，让操作系统自己想办法整活，我们就别管了。

操作系统会维护页缓存不需要你来维护 dirty page，
至于何时写入我记得是有策略吧。
因此并不是你进程写了就立刻执行写入的。

你说调度磁头就调度磁头啊。
无论是 A 进程还是 B 进程，都不能调度磁头。进程只能输出到文件，至于文件怎么写，写到哪里去，完全是操作系统在那里按着先来后到进行安排调度罢了。

不主动 fsync，进程写文件时，操作系统不一定真的写；并不是进程要求读多少文件内容，操作系统就读多少，可能多读一点。看下 pagecache 的相关文章能解决这个疑问不？

操作系统的意见也是很重要啊，你说转就转？

按照我的理解，都是写到内存了(file.write)，由操作系统来进行物理写入(file.flush)

磁头不是操作系统调度的，也不是进程调度的，是硬盘上的 BIOS 调度的，它会处理这一切，你只需要告诉硬盘需要在哪写数据就行。数据先保存在硬盘的缓存，至于要不要转动，何时写入由硬盘自己决定

我是这样理解的. 无论是追加还是随机写, **首次磁头寻道**的时间是**必须要做**的. 而追加写比随机写快是比较**寻道后的写速度**.
进程 A 顺序写, 进程 B 随机写, 同样的的时间片, A 写入的要远大于 B 写入数据, B 在运行期间会多次随机移动磁头速度, 即使有比较好的磁头调度还是避免不了再次寻道. 而 A 写入速度基本就是磁盘写入上限(转速)

总结：文件系统没法决定磁盘转不转。假如持续 3ms 丫要是转不到，那数据也到写缓存里了等着写盘。

很难做到进程 A 一直顺序写入吧，比如，在写入文件的时候，还有打印日志。磁盘又要转动磁头去写入日志文件。

你理解错了, 吞吐量比的是同一段时间内的读写字节数. 比如说跑车比公交快, 你不能拿跑车不跑时候跟公交跑的时候比速度吧?

没太理解这个比喻，意思是一个进程无法同时对多个文件进行追加写入吗？