IPFS共享更新文件的效率

阿尔珀

更新10-30-2019:

=>请参阅以下有关IPFS功能请求的讨论:git-diff功能:提高IPFS共享更新文件的效率。减少文件/块重复

=>请参阅以下讨论以获取更多信息。IPFS是否提供块级文件复制功能?


例如,userA添加了一个大小为1 GB的文件。IPFS add file.txtuserB通过IPFS将该文件放入其存储中。后来,userA发布了一个错误,并仅更改了文件上的单个字符,并希望与userB共享此更新版本

因此,userA再次通过ipfs add file在IPFS中进行了少量更改,添加了相同的文件,而userB必须获取该1 GB的文件,而不是更新该单个字符。有没有更好的方法来解决此问题,其中只有更新的版本才应由userB提取,就像git的工作原理一样git pull

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

进一步的调查:

我做了一个小实验。首先,我将1GB文件添加到IPFS中。后来,我更新了文件上的一小行,该行已经通过IPFS共享。我观察到userA再次重新推送了完整的1GB文件,而不是仅推送了包含已更改数据的数据块。我认为这是非常昂贵且耗时的。我已经共享了新的更新文件的哈希值,并再次完整的文件是通过下载IPFS对用户B,而不是只下载包含更改字符块。

  • 步骤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仅共享文件更新块的最佳解决方案是什么?


在此之上; 在同一节点上,只要执行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

分析:

两者(更新后的文件和原始文件)的回购大小都有相同的增加:

首先,我创建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个,因此它添加了完整的文件,更改了回购大小(38823)

$ ipfs repo stat
NumObjects: 5311
RepoSize:   181428647
StorageMax: 10000000000
RepoPath:   /home/alper/.ipfs
Version:    fs-repo@6
马修·斯蒂夫斯

IPFS目前尚不支持您所描述的方案,因为文件是通过其内容的哈希值编制索引的。在某些情况下,尽管由于文件分解成块的方式而导致此操作“意外”发生。如果更改发生在文件的末尾,则文件的开头可能具有与传输的“块”相同的散列。

可以分析当前存储的数据,并查看是否已经有一些可用于该块的数据(这与rsync如何实现此功能类似,尽管它使用了为该过程设计的校验和算法)

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章