两个进程操作同一个文件,一个在尾部追加写,一个从头开始读,对磁盘有什么影响呢

2020-10-10 15:24:14 +08:00
kakaxi9394  kakaxi9394

磁盘头是不是会一会儿 seek 到文件头部,一会儿 seek 到文件尾部?

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

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

3341 次点击
所在节点   Linux  Linux
11 条回复
zhusngqz
zhusngqz
2020-10-10 16:08:42 +08:00
同时的话应该是一个进程失败,或者阻塞吧!!! 我是怎么猜的
luckyrayyy
luckyrayyy
2020-10-10 16:09:54 +08:00
哈哈,很有意思的问题,直觉上感觉应该有个 cache 避免频繁切换吧。等个大佬的回答。
zhgg0
zhgg0
2020-10-10 16:20:12 +08:00
不会,应用层调用了写入,操作系统并不少马上就写磁盘,有 pagecache 。
bleoo
bleoo
2020-10-10 16:21:06 +08:00
你忘了 system-file-cache 这层
nekoyaki
nekoyaki
2020-10-10 16:24:21 +08:00
在看 kafka 的设计还能问出这种这个问题说明你没看懂,回去重看
sujin190
sujin190
2020-10-10 16:36:16 +08:00
磁盘头是不是会一会儿 seek 到文件头部??这是个啥操作! seek 只是切换了文件描述符内记录的文件当前读写文件位置罢了,和磁头也没啥关系吧,更不要说两个进程文件描述符信息都是独立的,有啥关系,实际读写触发磁头寻到的话,磁头始终在高速旋转在磁盘上,你不操作也有其他进程会触发磁头寻道的吧,而且 kafka 这种连续读写的方式来说,文件头和文件尾大概率在同已磁道上,消耗很小的吧,更不要说操作系统还有文件缓存
kakaxi9394
kakaxi9394
2020-10-10 18:00:07 +08:00
@zhusngqz 不至于
kakaxi9394
kakaxi9394
2020-10-10 18:18:35 +08:00
我知道内核文件对象有 read/write buffer,所以读写肯定是先经过内核 buffer,再到磁盘文件。
也知道 kafka 是线性读写,利用两种 buffer 已经极大程度上解决了问题。

我这里就只是好奇,是不是有极端情况: 一个日志文件同时读写,又恰好触发了内核 buffer 和磁盘文件的同步,就会出现“一会儿 seek 到文件头部,一会儿 seek 到文件尾部”的情况。

感觉是有可能的。我自己钻牛角尖罢了,纯粹好奇
gotonull
gotonull
2020-10-10 18:26:56 +08:00
2 个进程同时对一个文件操作,一个拿到写锁了,另一个应该不能读了吧
ryd994
ryd994
2020-10-10 18:27:56 +08:00
@kakaxi9394 Linux 默认是 CFQ 或者 deadline 磁盘调度器。读比写优先级高。所以会优先执行读操作。
写会延迟,然后多个连续的操作会被合并。
读实际上会有 readahead 机制参与。预读下一部分到缓存。所以可以说读操作也被合并了。

刚写入的文件内容就在 cache 里,不需要读。硬要做成 write trough cache 的话,可能会来回 seek,但不会非常频繁。硬要禁用 cache 和调度器的话才会来回 seek (但是硬盘本身还有 buffer )
jones2000
jones2000
2020-10-10 23:24:24 +08:00
用 SSD 不存在什么磁头问题。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/713669

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX