2

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

我正在为具有特定属性的所有文件搜索一个 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 操作很不满意。

4

3 回答 3

5

使用lsandgrep不仅速度更慢（增加了分叉、等待、读取和写入管道等的开销）；这也是不正确的。

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

于 2013-01-03T16:31:42.923 回答
4

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

于 2013-01-03T16:27:42.330 回答
2

我猜没有。两者都是同步操作，但你必须启动一个全新的递归进程，这有其自身的开销。如果您希望加快操作速度，我建议您使用 map/reduce 模型。

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

编辑：

正如许多人在这里所指出的，这是一个 IO 绑定的过程，map/reduce 的典型实现是一个具有许多 mapper 和 reducer 的并行系统，但这并不意味着您不能从将任务拆分为 map 函数中受益和一个减少功能。map/reduce模型仍然有用。

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

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

我所描述的并不完全是人们知道和熟悉的 map/reduce，但它足够相似，可以作为一个有用的起点。

于 2013-01-03T16:28:09.033 回答