两个进程操作同一个文件，一个在尾部追加写，一个从头开始读，对磁盘有什么影响呢
kakaxi9394 · 2020-10-10 15:24:14 +08:00 · 3300 次点击这是一个创建于 1534 天前的主题，其中的信息可能已经有所发展或是发生改变。
磁盘头是不是会一会儿 seek 到文件头部，一会儿 seek 到文件尾部？
最近在看 kafka 的存储设计，想到 broker 一般追加新消息到日志文件，一边读日志文件给 consumer 发消息。如果读写进度有很大差别，磁盘 seek 的开销是不是会变大？
即使 linux 内核有 page cache，是不是也会出现这个问题？
 |
1
zhusngqz 2020-10-10 16:08:42 +08:00
同时的话应该是一个进程失败，或者阻塞吧！！！ 我是怎么猜的
|
 |
2
luckyrayyy 2020-10-10 16:09:54 +08:00
哈哈，很有意思的问题，直觉上感觉应该有个 cache 避免频繁切换吧。等个大佬的回答。
|
 |
3
zhgg0 2020-10-10 16:20:12 +08:00
不会，应用层调用了写入，操作系统并不少马上就写磁盘，有 pagecache 。
|
 |
4
bleoo 2020-10-10 16:21:06 +08:00
你忘了 system-file-cache 这层
|
 |
5
nekoyaki 2020-10-10 16:24:21 +08:00
在看 kafka 的设计还能问出这种这个问题说明你没看懂，回去重看
|
 |
6
sujin190 2020-10-10 16:36:16 +08:00  1
磁盘头是不是会一会儿 seek 到文件头部？？这是个啥操作！ seek 只是切换了文件描述符内记录的文件当前读写文件位置罢了，和磁头也没啥关系吧，更不要说两个进程文件描述符信息都是独立的，有啥关系，实际读写触发磁头寻到的话，磁头始终在高速旋转在磁盘上，你不操作也有其他进程会触发磁头寻道的吧，而且 kafka 这种连续读写的方式来说，文件头和文件尾大概率在同已磁道上，消耗很小的吧，更不要说操作系统还有文件缓存
|
 |
7
kakaxi9394 OP @zhusngqz 不至于
|
|
8
kakaxi9394 OP 我知道内核文件对象有 read/write buffer，所以读写肯定是先经过内核 buffer，再到磁盘文件。
也知道 kafka 是线性读写，利用两种 buffer 已经极大程度上解决了问题。 我这里就只是好奇，是不是有极端情况： 一个日志文件同时读写，又恰好触发了内核 buffer 和磁盘文件的同步，就会出现“一会儿 seek 到文件头部，一会儿 seek 到文件尾部”的情况。 感觉是有可能的。我自己钻牛角尖罢了，纯粹好奇 |
 |
9
gotonull 2020-10-10 18:26:56 +08:00
2 个进程同时对一个文件操作，一个拿到写锁了，另一个应该不能读了吧
|
 |
10
ryd994 2020-10-10 18:27:56 +08:00
@kakaxi9394 Linux 默认是 CFQ 或者 deadline 磁盘调度器。读比写优先级高。所以会优先执行读操作。
写会延迟，然后多个连续的操作会被合并。 读实际上会有 readahead 机制参与。预读下一部分到缓存。所以可以说读操作也被合并了。 刚写入的文件内容就在 cache 里，不需要读。硬要做成 write trough cache 的话，可能会来回 seek，但不会非常频繁。硬要禁用 cache 和调度器的话才会来回 seek （但是硬盘本身还有 buffer ） |
 |
11
jones2000 2020-10-10 23:24:24 +08:00
用 SSD 不存在什么磁头问题。
|
Select Language