Question

我有一个可以使用理论答案的问题。

我在一个大的100 + TB卷上搜索具有特定属性的所有文件。为此，我一直在使用“查找”命令，因为它可以完成我想要的所有操作。

也就是说，除了在合理的时间内运行。我意识到在任何情况下遍历庞大的文件系统都会非常耗时，但我可能会遇到一个可能的解决方案。

如果可能的话，会递归地使用ls和grep怎么办？注意：下面的代码并不意味着语法正确。这只是为了说明。

my_ls{
    # get a listing of all files in the directory passed
    var=`ls -lsa $1`
    # iterate over each file/directory returned by ls
    for each file/directory in $var
        if $each is a directory
            my_ls $each
    done
    # search the lines output from ls for the attributes
    echo $var | grep $searchstring
}

这个想法总体上要比找到大型文件系统更快吗？内存需求可能会很快变大，但不会太大。 ~~也可以将其并行化，并将线程卸载到GPU以便更快地处理（不是我知道的bash，但一般而言）。~~

~~编辑：是的，在大多数情况下，我建议对io-bound操作进行并行化是非常暗淡的。~~

Answer 1

使用ls和grep不仅速度慢（增加了分支，等待，读取和写入管道的开销等）;它也不正确。

请参阅http://mywiki.wooledge.org/ParsingLs，了解为什么在脚本中使用ls是邪恶的（在“导致错误，其中一些是安全可利用的”意义上）。

Answer 2

我强烈怀疑重复产生进程的开销远远超过find将花费多少资源。您应该考虑资源瓶颈在哪里，并且为了导航文件系统，它将成为磁盘访问。 CPU可以忽略不计。

Answer 3

我猜不是。两者都是同步操作，但是你必须启动一个全新的递归过程，它有自己的开销。如果您想要进行操作，我建议您使用map / reduce模型。

通常在解析文件或数据库内容时使用map / reduce，但这个想法可以适应您的情况。以下是map / reduce的简介：http://www-01.ibm.com/software/data/infosphere/hadoop/mapreduce/

编辑：

正如许多人在这里指出的那样，这是一个IO绑定过程，map / reduce的典型实现是一个具有许多映射器和缩减器的并行系统，但这并不意味着你无法将任务分成map函数和reduce函数。地图/缩小模型仍然有用。

对于我提出的建议，映射器应该是一个以递归方式查找指定路径下的所有文件的线程。然后，reducer评估文件是否由正确的用户（或您拥有的任何谓词）拥有。

这将IO与评估分离，这意味着IO线程永远不会暂停评估。这可能只会为每个文件节省一微秒，但在大型文件系统上，它可以节省大量成本。

我所描述的并不完全是地图/减少人们所知道并且感觉舒服，但它足够类似于一个有用的起点。

recursive ls和grep会比在大型文件系统上查找更快吗？

3 个答案: