☰

grep -r 某物/var/named

tag-icon • tag-icon linux x86-64
grep -r 某物/var/named

问题始于一条消息No space left on device。经过一番调查（在谷歌的帮助下），我发现：

查找：检测到文件系统循环；/var/named/chroot/var/named' is part of the same file system loop as/var/named'。

我不知道下一步该做什么。我在 centos.org 上找到了这个：

and see if the inode numbers are the same (they shouldn't be). If they are then you need to remove the /var/named/chroot/var/named/ hard link and recreate it as a directory

inode 编号相同，但我不知道具体要删除哪个文件夹以及下一步该做什么

感谢您的任何帮助

Linux xxxxx.onlinehome-server.info 2.6.32-220.13.1.el6.x86_64 #1 SMP 2012 年 4 月 17 日星期二 23:56:34 BST x86_64 x86_64 x86_64 GNU/Linux

答案1

如果这是有意的 bind-chroot 安装的一部分（我相信），当您删除目录并重新创建它时，inode 编号当然会有所不同。但是，一旦您重新启动命名服务，它的 init 脚本将再次将 --bind /var/named 挂载到 var/named/chroot/var/named，您将逻辑上再次看到相同的 inode 编号。

我浪费了一些时间试图弄清楚这是否正常，更令人困惑的是，我网站上的一些傻瓜认为一些自定义的初始化脚本是个好主意，所以我真的不知道什么是正常的了。

显然，这可能是使用 bind-chroot 的 centos 上的标准行为，但我觉得很难相信，因为任何导致类似事情的事情都会导致：

grep -r 某物/var/named

grep：内存耗尽

（在配备 16GB RAM 的 R610 上）

这是我很长时间以来见过的最愚蠢的事情之一。

有人知道这是否是 bind-chroot 的常规行为吗？如果是，我不得不说在 redhat/centos 上远离它。我绝对不会向任何认真做事的人推荐这些发行版。

答案2

您引用的建议指出

删除 /var/named/chroot/var/named/ 硬链接并将其重新创建为目录

因此你应该这样做：

rm -f /var/named/chroot/var/named
mkdir /var/named/chroot/var/named

相关内容