IPFS资源缓冲与回收

  • 0_1548317175415_13d266a5-49d4-4b5a-83bc-0cefa870d352-image.png


    星际文件系统IPFS)上的节点通过garbage collector(垃圾回收站)下载缓存资源,并使这些资源可以上传到其他节点,从而在此过程中创建分布式分发网络。该系统依赖于有意愿的、能够进行缓存的、同时与网络共享资源的节点。但是,存储空间不是无限的,因此节点需要清除部分缓存,为新的资源腾出空间。

    --

    本文主要讨论ipfs-go 0.4.18版本中的缓存垃圾收集实现,以及特定于该实现的默认行为

    --

    描述IPFS的博客文章延续了一个常见的说法,IPFS节点的整个资源缓存每小时都会进行垃圾回收和删除。但是,默认情况下甚至不启用垃圾回收站,除非手动运行垃圾回收或按计划运行,否则缓存可以无限制地增长。

    --

    当启用10 GB默认最大缓存存储空间(由storagemax选项配置)时,存储库垃圾回收站将每小时运行一次(由gcperiod选项配置)。

    --

    当垃圾回收站运行时,将一次性删除整个缓存;它不仅能够删除足够的数据,还可以将总大小降低到可用大小的90%。垃圾回收站永远不会删除固定资源。

    --

    单个用户用于网络浏览的节点,不太可能超过每小时的最大存储量;并且启用垃圾回收后,缓存资源可以保留数小时、数天或数周,具体取决于使用情况。一个流行的公共网关节点,可能比单个用户使用的节点,更频繁地被清除。但是,公共网关可以使用自己的垃圾回收处理。

    --

    ipfs-go 0.4.4 版本(2016年10月10日)和更高版本有一个任意限制,允许垃圾收回收站在达到允许缓存时间的90%后,每GB剩余的缓存空间只运行一分钟。这将在允许的时间内删除不确定数量的数据,并且可能不足以使缓存低于StorageGCWatermark。在0.4.5版本中删除此方法之后,在ipfs-go master中没有看到限制缓存清除行为的其他尝试,因此可以确定的是此方法已被删除。

    --

    IPFS的缓存处理肯定有改进的空间。当节点超过配置存储容量的一个字节时,节点不应删除整个缓存,而是应该更智能地开始清除内容。例如,它可以首先删除缓存中一些很早的和最不频繁访问的内容。它可以潜在的查询网络,并删除由共享该资源节点数决定的最广泛分布的资源。甚至在释放足够的存储空间之前随机进行资源删除也是一种改进。


    【往期文章】

    -全球最大盗版资源网站“海盗湾” 上线IPFS!

    -2019年五大最期待的区块链项目

    -IPFS最新动态-25

    --
    本文由Daniel 发表于ctrl博客,经由Filecoin中国社区翻译整理。


    识别二维码进入IPFS社群

    0_1548317371175_1edfb018-1819-4c4b-81dd-3033dda57262-image.png

Log in to reply
 

Email:filapp@protonmail.com

Twitter:

https://twitter.com/RalapXStartUp

Telegram:

https://t.me/bigdog403

全球Filecoin中文爱好者网站

友情链接: 黑池
  • X

    @xiedapao
    If there does exist such a thing, I cannot find it.

    zenground0 [7 hours ago]
    I don't believe there is

    zenground0 [7 hours ago]
    tho maybe phritz has some "refactor the vm" issues that are relevant

    laser [7 hours ago]
    I assert to you that we must create an InitActor in order for CreateStorageMiner conform to the specification.

    Why [7 hours ago]
    I’ll take things I don’t disagree with for $400 Alex

    zenground0 [7 hours ago]
    Agreement all around. However this is one of those changes that is pretty orthogonal to getting the storage protocol to work and something we can already do. We need to track it but I see it as a secondary priority to (for example) getting faults or arbitrating deals working.

    anorth [3 hours ago]
    Thanks @zenground0, I concur. Init actor is in our high-level backlog, but I'm not surprised there's no issue yet. Is it reasonable to draw our boundary there for now?

    阅读更多
  • X

    Does there already exist a story which addresses the need to create an InitActor?

    阅读更多
  • X

    @xiedapao [filecoin mining]
    I believe that a solution to this problem is that the rust-fil-proofs CircleCI build needs to be modified to link the libfilecoin_proofs.a archive file to a dummy C program using the same pkg-config file which go-filecoin uses.

    阅读更多
  • X

    @xiedapao [filecoin mining]
    The libfilecoin_proofs.a file has a few dynamic dependencies - things we can't link in statically, like glibc - and the linker flags have to been updated manually. Unfortunately, rust-fil-proofs CircleCI build doesn't try to link the libfilecoin_proofs.a file, so we don't know when we get the linker flags wrong until we've already updated the go-filecoin submodule SHA.

    阅读更多

Looks like your connection to Filecoin.cn中国爱好者社区 was lost, please wait while we try to reconnect.