- 主题:copy文件速度跟啥有关?
你不是说你有200G的内存吗?os完全可以拿它们来缓存硬盘文件了。
【 在 chunhui 的大作中提到: 】
: 我理解是它不太可能缓存这么多文件。10多个G
--
FROM 1.28.125.*
其他程序读,也是读的内存里的文件数据。此时并没有刷到硬盘上。
【 在 chunhui 的大作中提到: 】
: 我是copy过去之后其他程序立刻就开始读了。
--
FROM 1.24.229.*
是不是引用,你自己做一下实验吧。
【 在 chunhui 的大作中提到: 】
: 有没有可能,因为这些文件没有修改,文件系统只是增加了引用而已?
--
FROM 1.24.229.*
建议你仔细看看 Linux kernel development 这本书的 The Page Cache and Page Writeback 这一章节。第3版的第16章。我目前也在看。开头第一句就是
The Linux kernel implements a disk cache called the page cache.The goal of this cache is to minimize disk I/O by storing data in physical memory that would otherwise require disk access.
【 在 chunhui 的大作中提到: 】
: 怎么搞可以验证?
--
修改:SlO FROM 111.193.233.*
FROM 111.193.233.*
如果你确定copy只是增加计数的话,这个动作是不是跟文件系统有关系?不同的文件系统对于copy处理的方式不同。你服务器上用的什么文件系统?
【 在 chunhui 的大作中提到: 】
: 不是这个原因。单纯copy并没有cache。而是增加了一个链接引用计数而已。它甚至都没有后把内容读到内存。
: 我压缩这个目录。就慢起来了。算是压缩的时间和读取的时间,感觉是正常的时间长度。
--
FROM 124.64.17.*
我在网上找到一篇关于xfs reflink 的文章,貌似可以解释这个现象。无法发连接。
可以搜索以下
Darrick Wong xfs-data-block-sharing-reflink
XFS - Data Block Sharing (Reflink)
January 6, 2020 | 5 minute read
【 在 chunhui 的大作中提到: 】
: 我压缩目录,就看起来时间正常了。说明读取了。
: xfs
--
修改:SlO FROM 124.64.17.*
FROM 124.64.17.*