跳至主要內容
  • Hostloc 空間訪問刷分
  • 售賣場
  • 廣告位
  • 賣站?

4563博客

全新的繁體中文 WordPress 網站
  • 首頁
  • 两个进程操作同一个文件,一个在尾部追加写,一个从头开始读,对磁盘有什么影响呢
未分類
9 10 月 2020

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

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

資深大佬 : kakaxi9394 6

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

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

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

大佬有話說 (11)

  • 資深大佬 : zhusngqz

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

  • 資深大佬 : luckyrayyy

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

  • 資深大佬 : zhgg0

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

  • 資深大佬 : bleoo

    你忘了 system-file-cache 这层

  • 資深大佬 : nekoyaki

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

  • 資深大佬 : sujin190

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

  • 主 資深大佬 : kakaxi9394

    @zhusngqz 不至于

  • 主 資深大佬 : kakaxi9394

    我知道内核文件对象有 read/write buffer,所以读写肯定是先经过内核 buffer,再到磁盘文件。
    也知道 kafka 是线性读写,利用两种 buffer 已经极大程度上解决了问题。

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

    感觉是有可能的。我自己钻牛角尖罢了,纯粹好奇

  • 資深大佬 : gotonull

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

  • 資深大佬 : ryd994

    @kakaxi9394 Linux 默认是 CFQ 或者 deadline 磁盘调度器。读比写优先级高。所以会优先执行读操作。
    写会延迟,然后多个连续的操作会被合并。
    读实际上会有 readahead 机制参与。预读下一部分到缓存。所以可以说读操作也被合并了。

    刚写入的文件内容就在 cache 里,不需要读。硬要做成 write trough cache 的话,可能会来回 seek,但不会非常频繁。硬要禁用 cache 和调度器的话才会来回 seek (但是硬盘本身还有 buffer )

  • 資深大佬 : jones2000

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

文章導覽

上一篇文章
下一篇文章

AD

其他操作

  • 登入
  • 訂閱網站內容的資訊提供
  • 訂閱留言的資訊提供
  • WordPress.org 台灣繁體中文

51la

4563博客

全新的繁體中文 WordPress 網站
返回頂端
本站採用 WordPress 建置 | 佈景主題採用 GretaThemes 所設計的 Memory
4563博客
  • Hostloc 空間訪問刷分
  • 售賣場
  • 廣告位
  • 賣站?
在這裡新增小工具