【发布时间】:2020-07-20 19:06:03
【问题描述】:
我倾向于漫无边际,因此,如果为了削减谷壳而导致上下文较少(或者我只是悲惨地失败并且仍然漫无目的),我会提前道歉。
我正在尝试改进我编写的一些工具,用于将大量数据从一个网络存储位置同步到另一个以进行归档(第二个网络位置是更大磁带库系统的一部分)。由于大量共享资源,目录中通常有大量硬链接文件需要移动,我使用 rsync 来保留这些链接。
在 1TB 的实际数据区域中,当硬链接被“包含”到总数中时,Rsync 可能会大 4 或 5 倍(即 4 - 5TB)并不少见或意外。
出于各种原因,我需要对源中的数据进行哈希处理并与目标数据进行比较AND 记录该哈希结果(包括哈希)。因此,如果恢复的数据意外损坏,我可以比较恢复数据的哈希值和同一文件最初 rsync 时的哈希值,以确定何时/是否发生损坏。
rsync 发生后,我使用以下命令对源进行 md5(任何哈希都可以,但我没有具体原因选择 md5):
find . -type f -exec md5sum "{}" + > $temp_file
$temp_file 的输出也会回显到我的主输出文件中。然后移动到目的地并运行(这样做是先源然后目的地,好像文件夹正在合并,它只会散列在这个最新的rsync中移动的文件):
md5sum -c $temp_file >> $output_file
一切都很好,这确实有效除了,这将散列所有文件,包括硬链接,实际上,找到一遍又一遍地重复相同的文件,这可能会增加整个过程的时间。
有没有办法编辑 'find....' 命令以忽略硬链接文件,但是 仍然散列硬链接文件中的“原始”文件链接实际上指向。我确实研究了以下内容:
find . -type f -links 1
但我担心的是所有与硬链接相关的文件都将被忽略,而不是列出实际占用该 inode 的“原始”文件,并排除随后指向该 inode 的所有文件。
我对 -links 1 忽略所有硬链接相关文件是否正确,如果是,我该怎么办?
【问题讨论】:
-
你可以编写一个备忘录脚本来构建一个 inode → 哈希缓存以避免重复计算。
-
所有常规文件都是硬链接。如果一个 inode 有多个硬链接,则您无法判断哪个链接是首先创建的。您可以通过例如记住哈希值找到输出 inode 编号和文件名后,在
while read循环中读取它们,并使用关联数组来跟踪您是否已经处理过这个 inode -
谢谢你们,这个信息很有帮助,也暴露了一些我真的不明白的地方(即所有常规文件都是硬链接),我很感激你们的信息!!