Lubuntu updatedb.locate 可能会 scap 绑定挂载的 nfs 文件系统

Lubuntu updatedb.locate 可能会 scap 绑定挂载的 nfs 文件系统

我注意到cron.daily那次运行updatedb.locate要花很长时间才能完成(如果能完成的话)。我中断了上次运行,发现它占用了超过 16 小时的 CPU 时间。

经过一番调查,我发现 find 正在索引巨大的 nfs 挂载文件系统。尽管 nfs 被列为应跳过的文件系统之一,但它本身PRUNEFS /etc/updatedb.conf也是如此:PRUNEFS/etc/cron.daily/locate

illia@illia-vm1:~$ grep PRUNEFS /etc/cron.daily/locate 
PRUNEFS="NFS nfs nfs4 afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf ocfs2"
export FINDOPTIONS PRUNEFS PRUNEPATHS NETPATHS LOCALUSER

事实证明,如果文件系统在其他地方绑定挂载,find 将看不到它的实际类型,而是将其视为类型为“none”:

illia@illia-vm1:~$ mount | grep /shared
/shared on /var/lib/schroot/mount/<cut>/shared type none (ro,bind)
<cut>:/shared on /shared type nfs (ro,intr,soft,tcp,bg,nordirplus,addr=<cut>)

illia@illia-vm1:~$ find /shared -printf "%F %p\n"
none /shared
none /shared/<cut>
none /shared/<cut>
none /shared/<cut>
none /shared/<cut>
...

我找到了一个相当古老的 Debian 错误来讨论这个问题:

http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=14921 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329385

我可以自己修复此问题,方法是将“none”添加到PRUNEFS/etc/updatedb.conf,然后创建/etc/updatedb.findutils.cron.local也将“none”添加到的版本PRUNEFS

我想知道此时正确的做法是什么?Debian 错误似乎只是表明问题存在,find最好修复。我想既然有一个解决方法,这个错误实际上并没有给任何人带来太多困扰。我不知道 Debian 发行版中是否有解决方法,但它似乎没有出现在 Lubuntu(我猜还有 Ubuntu)中。我应该怎么做才能将该解决方法应用于 Ubuntu 系统?

答案1

最好的办法是提交错误一旦你有了错误追踪编号,提出新问题并询问是否有其他人遇到此问题并要求他们针对您的错误提交错误报告以便它“影响多个用户”然后它将得到解决(可能以“无”作为PRUNEFS标准...

公平警告:提交错误报告是一项繁重的工作,所以这就是为什么每个发现这个问题的人(包括我)都只是耸耸肩,在自己的系统上纠正它,然后继续前进。这个错误需要大量数据才能影响你,所以你可能正在运行一个服务器……我的解决方案是耸耸肩,将所有 NTFS 分区复制到 EXT4 后删除它们……

相关内容