![btrfs中频繁du的性能和影响](https://linux22.com/image/192361/btrfs%E4%B8%AD%E9%A2%91%E7%B9%81du%E7%9A%84%E6%80%A7%E8%83%BD%E5%92%8C%E5%BD%B1%E5%93%8D.png)
我正在分析安排 crondu
每小时在几个大文件夹(总共 10-20TB 文件,# 个文件少于 100.000)上运行的影响。
据我了解,du
它stats
读取缓存在 RAM 中的 inode 信息。它是否正确?或者是磁盘缓存?或两者?
如果以上是正确的,我可以假设du
频繁跑步会:
- 不会对我的系统性能产生负面影响
- 不会对主轴造成不必要的磨损?这可能是一个有争议的问题,但只是幽默一下
我读到了几种提供某种输出缓存的工具,du
但我的目标是捕捉差异,因此不确定它们与讨论相关。
多谢!
答案1
据我了解,du 使用 stats 来读取缓存在 RAM 中的 inode 信息。它是否正确?或者是磁盘缓存?或两者?
“缓存在 RAM 中”:是的,在某种程度上。不完全是这样,因为文件系统缓冲区也会消耗 RAM,并且 100000 个 inodes/extent 列表也需要 RAM,所以“两者”。 (“磁盘缓存”没有什么意义:数据结构位于磁盘上,因此这不是缓存,而是底层数据)。
如果上述正确,我可以假设频繁运行 du 会:
- 不会对我的系统性能产生负面影响
你不能这样假设。即使整个文件系统位于 RAM 中,这仍然是数据密集型操作,并且将使用 CPU 以及 RAM 和驱动器接口带宽。
不会对主轴造成不必要的磨损?这可能是一个有争议的问题,但只是幽默一下
我从未见过主轴磨损,所以,嗯,不是吗?另外,当你的硬盘在使用时,它会旋转 - 所以,不太确定这个问题是否经过深思熟虑!
我读到了一些为 du 输出提供某种缓存的工具,但我的目标是捕捉差异,因此不确定它们与讨论相关。
如果你追求改变,你可能会倒退。du
可能是不是那就选择工具吧!
- 实际上,您可以使用 inotify 来获取有关文件属性更改的通知。这比仅仅为了进行一些更改而遍历整个文件系统的负载要少!
du
在 BTRFS 上会在使用的存储空间方面欺骗您。 Btrfs 很聪明——复制的文件在写入之前不需要额外的存储,稀疏文件区域也不需要,并且快照和子卷的概念使得这一切在概念上有点困难。du
只是将所有文件大小相加。不一样磁盘使用情况!
du
我建议你提出一个新问题(新帖子,而不是评论),在其中详细描述你试图解决的问题,并描述你当前的方法。您在这里的问题似乎是在询问一种非常具体的方法的一个小方面,我不确定这种方法是否能解决您的实际问题!