☰

btrfs中频繁du的性能和影响

tag-icon • tag-icon filesystems hard-disk disk-usage btrfs storage
btrfs中频繁du的性能和影响

我正在分析安排 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可能是不是那就选择工具吧！

  1. 实际上，您可以使用 inotify 来获取有关文件属性更改的通知。这比仅仅为了进行一些更改而遍历整个文件系统的负载要少！
  2. du在 BTRFS 上会在使用的存储空间方面欺骗您。 Btrfs 很聪明——复制的文件在写入之前不需要额外的存储，稀疏文件区域也不需要，并且快照和子卷的概念使得这一切在概念上有点困难。du只是将所有文件大小相加。不一样！

du我建议你提出一个新问题（新帖子，而不是评论），在其中详细描述你试图解决的问题，并描述你当前的方法。您在这里的问题似乎是在询问一种非常具体的方法的一个小方面，我不确定这种方法是否能解决您的实际问题！

相关内容