ipfs - IPFS共享更新文件的效率

Question

2019 年 10 月 30 日更新:

=> 请参阅以下对 IPFS 功能请求的讨论:git-diff feature: Improve efficiency of IPFS for sharing updated file. Decrease file/block duplication

=> 请参阅以下讨论以获取更多信息。 Does IPFS provide block-level file copying feature?

---

例如 userA 添加了一个 1 GB 的文件。 IPFS add file.txt userB 通过 IPFS 将该文件放入他的存储中。后来 userA 发布了一个错误，只更改了文件中的一个字符，并想与 userB 分享这个更新版本。

因此 userA 再次通过 ipfs add file 将相同的文件添加到 IPFS 中并进行了一些小的改动| , 和 userB 必须获取 1 GB 的文件而不是更新单个字符。有没有更好的方法来解决这个问题，userB 应该只拉更新版本，就像我们做 git pull 时 git 的工作方式一样？

Git 有更好的方法，请参阅 ( https://stackoverflow.com/a/8198276/2402577)。 IPFS 是否像 Git 一样使用增量压缩进行存储(https://gist.github.com/matthewmccullough/2695758)？或类似的方法？

进一步调查:

我做了一个小实验。首先我在 IPFS 中添加了 1GB 的文件。后来，我更新了文件中的一小行，该文件已通过 IPFS 共享。我观察到 userA 再次推送完整的 1GB 文件，而不是只推送包含更改数据的 block 。在我看来，这是非常昂贵和耗时的。我已经共享了新更新文件的哈希值，并再次通过 IPFS 在 userB 上下载完整文件，而不是只下载包含更改字符的 block 。

• 第 1 步:

用户A

$ fallocate -l 1G gentoo_root.img
$ ipfs add gentoo_root.img
 920.75 MB / 1024.00 MB [========================================>----]  89. 92added QmdiETTY5fiwTkJeERbWAbPKtzcyjzMEJTJJosrqo2qKNm gentoo_root.img

---

用户B

$ ipfs get QmdiETTY5fiwTkJeERbWAbPKtzcyjzMEJTJJosrqo2qKNm
Saving file(s) to QmdiETTY5fiwTkJeERbWAbPKtzcyjzMEJTJJosrqo2qKNm
 1.00 GB / 1.00 GB [==================================] 100.00% 49s

---

• 第 2 步:

用户A

$ echo 'hello' >> gentoo_root.img
$  ipfs add gentoo_root.img   # HERE node pushing 1 GB file into IPFS again. It took 1 hour for me to push it, instead only updated the changed block.
32.75 MB / 1.00 GB [=>---------------------------------------]   3.20% 1h3m34s
added Qmew8yVjNzs2r54Ti6R64W9psxYFd16X3yNY28gZS4YeM3 gentoo_root.img

用户B

# HERE complete 1 GB file is downloaded all over again.
ipfs get Qmew8yVjNzs2r54Ti6R64W9psxYFd16X3yNY28gZS4YeM3
[sudo] password for alper:
Saving file(s) to Qmew8yVjNzs2r54Ti6R64W9psxYFd16X3yNY28gZS4YeM3
 1.00 GB / 1.00 GB [=========================] 100.00% 45s

[Q] 在这一点上，通过 IPFS 共享更新文件而不重新共享更新文件的整个版本以及 IPFS 仅共享更新文件 block 的最佳解决方案是什么？文件？

---

除此之外；每当我做 ipfs cat <hash> 时都在同一个节点上它会重新下载相同的哈希值。

$ ipfs cat Qmew8yVjNzs2r54Ti6R64W9psxYFd16X3yNY28gZS4YeM3
 212.46 MB / 1.00 GB [===========>---------------------------------------------]  20.75% 1m48s

$ ipfs cat Qmew8yVjNzs2r54Ti6R64W9psxYFd16X3yNY28gZS4YeM3
 212.46 MB / 1.00 GB [===========>---------------------------------------------]  20.75% 1m48s

---

分析:

两者(更新文件和原始文件)在 repo 大小上有相同的增加:

首先我创建了 100 MB 的文件 (file.txt)

NumObjects: 5303
RepoSize:   181351841
StorageMax: 10000000000
RepoPath:   /home/alper/.ipfs
Version:    fs-repo@6

---

   $ ipfs add file.txt
   added QmZ33LSByGsKQS8YRW4yKjXLUam2cPP2V2g4PVPVwymY16 file.txt
   $ ipfs pin add QmZ33LSByGsKQS8YRW4yKjXLUam2cPP2V2g4PVPVwymY16

这里的对象数量增加了 4。更改了存储库大小 (37983)

$ ipfs repo stat
NumObjects: 5307
RepoSize:   181389824
StorageMax: 10000000000
RepoPath:   /home/alper/.ipfs
Version:    fs-repo@6

比我做的echo 'a' >> file.txt然后ipfs add file.txt

在这里我观察到对象的数量增加了 4 个，所以它添加了完整的文件，改变了 repo 大小 (38823)

$ ipfs repo stat
NumObjects: 5311
RepoSize:   181428647
StorageMax: 10000000000
RepoPath:   /home/alper/.ipfs
Version:    fs-repo@6

Answer 1

IPFS 目前的设计并不支持您描述的场景，因为这些文件是通过其内容的哈希索引的。由于文件被分解成 block 的方式，在某些情况下这会“意外地”起作用。如果更改发生在文件末尾，则文件开头可能具有与传输的“ block ”相同的哈希值。

可以分析当前存储的数据并查看您是否已经拥有可用于该 block 的数据(这与 rsync 实现此目的的方法类似，尽管它使用为此设计的校验和算法过程)