流rdiff - delta差分?

我有一个使用rdiff进行在线备份的产品。目前发生的是: 将文件复制到临时区域(因此在我们处理文件时,文件不会消失或被修改) 散列原始文件,并计算rdiff签名(用于差异差分) 计算rdiff delta差异(如果我们没有先前版本,则跳过此步骤) 压缩&加密产生的差异 目前,这些阶段彼此明显不同。最终结果是我们多次遍历文件。对于小文件,这不是什么大问题(特别是给定磁盘缓存),但对于大文件(10或甚至100的GB),这是一个真正的性能杀手。 我想将所有这些步骤合并为一个读/写传递。 为此,我们必须能够以流式方式执行上述所有步骤,同时仍然保留所有“输出” - 文件散列,rdiff签名,压缩和放大。加密差值差异文件。这将需要从源文件中读取一个数据块(例如,100k?),然后在内存中迭代文件以更新散列,rdiff签名,执行增量差异,然后将输出写入压缩/加密输出流。我们的目标是大大减少我们所做的磁盘颠簸。 目前,我们使用rdiff.exe(它是底层librsync库之上的一个薄层)来计算签名并生成二进制增量。这意味着这些是在单独的过程中完成的,并且以一次性而非流式方式完成。 如何使用librsync库来实现我需要的功能?     
已邀请:
您可以完全跳过第1步。文件打开时无法删除,打开文件时选择适当的锁定标志也可以防止它被修改。例如,CreateFile函数采用dwShareMode参数。 您需要先计算整个rdiff签名,然后才能开始创建rdiff delta。您可以通过计算签名然后一次为文件的每个(例如)100 MB块增加分数来避免读取整个文件。你会以这种方式失去一些压缩效率*。您也可以考虑从rdiff切换到xdelta,它可以在输入中一次创建一个delta文件。 压缩和加密可以与计算delta相关联。如果压缩和加密是由单独的程序完成的,它们通常允许从标准输入读取并写入标准输出。这可以通过批处理文件中的管道最简单地使用,例如:
rdiff signature oldfile oldfile.sig
rdiff delta oldfile.sig newfile | gzip -c | gpg -e -r ... > compressed_encrypted_delta
如果在程序中使用库进行压缩/加密,则需要选择支持流操作的库。 *如果数据在文件中移动,则会失去很多效率。如果有人将100 MB预先设置为10 GB文件,rdiff将生成大约100 MB的增量文件。 rdiff一次以100 MB或更少的块完成,将产生大约10 GB的delta。 200 MB的块将产生大约5 GB的增量,因为每个块中只有一半的数据来自旧版本文件的相应块。     

要回复问题请先登录注册