磁盘头是不是会一会儿 seek 到文件头部，一会儿 seek 到文件尾部？

最近在看 kafka 的存储设计，想到 broker 一般追加新消息到日志文件，一边读日志文件给 consumer 发消息。如果读写进度有很大差别，磁盘 seek 的开销是不是会变大？

即使 linux 内核有 page cache，是不是也会出现这个问题？

同时的话应该是一个进程失败，或者阻塞吧！！！ 我是怎么猜的

哈哈，很有意思的问题，直觉上感觉应该有个 cache 避免频繁切换吧。等个大佬的回答。

不会，应用层调用了写入，操作系统并不少马上就写磁盘，有 pagecache 。

你忘了 system-file-cache 这层

在看 kafka 的设计还能问出这种这个问题说明你没看懂，回去重看

磁盘头是不是会一会儿 seek 到文件头部？？这是个啥操作！ seek 只是切换了文件描述符内记录的文件当前读写文件位置罢了，和磁头也没啥关系吧，更不要说两个进程文件描述符信息都是独立的，有啥关系，实际读写触发磁头寻到的话，磁头始终在高速旋转在磁盘上，你不操作也有其他进程会触发磁头寻道的吧，而且 kafka 这种连续读写的方式来说，文件头和文件尾大概率在同已磁道上，消耗很小的吧，更不要说操作系统还有文件缓存

不至于

我知道内核文件对象有 read/write buffer，所以读写肯定是先经过内核 buffer，再到磁盘文件。
也知道 kafka 是线性读写，利用两种 buffer 已经极大程度上解决了问题。
我这里就只是好奇，是不是有极端情况： 一个日志文件同时读写，又恰好触发了内核 buffer 和磁盘文件的同步，就会出现“一会儿 seek 到文件头部，一会儿 seek 到文件尾部”的情况。
感觉是有可能的。我自己钻牛角尖罢了，纯粹好奇

2 个进程同时对一个文件操作，一个拿到写锁了，另一个应该不能读了吧

Linux 默认是 CFQ 或者 deadline 磁盘调度器。读比写优先级高。所以会优先执行读操作。
写会延迟，然后多个连续的操作会被合并。
读实际上会有 readahead 机制参与。预读下一部分到缓存。所以可以说读操作也被合并了。
刚写入的文件内容就在 cache 里，不需要读。硬要做成 write trough cache 的话，可能会来回 seek，但不会非常频繁。硬要禁用 cache 和调度器的话才会来回 seek （但是硬盘本身还有 buffer ）

用 SSD 不存在什么磁头问题。