Post ASSckRCVcpZAxnHd0y by bgme@bgme.me
(DIR) More posts by bgme@bgme.me
(DIR) Post #ASMf4ziC3e0okVH2Js by lgE@mstdn.one
2023-02-05T09:05:11Z
0 likes, 1 repeats
简单讨论一下将 #IPFS 用于长毛象媒体存储的可行性如果在用户端用ipfs，要么自带网关，要么走第三方公共网关。（如果有其他思路也可讨论）前者占空间、CPU，同时速度还难以保证。后者就称不上是去中心化了。即使实例建网关转成http，那相比现在也没提供什么增益。服务端用ipfs，一种思路是把它当成s3用、直接托管在第三方，另一种则是在已有存储的基础上加入ipfs。前者如果完全依托IPFS交互，延时恐怕控制不住（固定提供商的peers？）。后者是我认为有一定可行性的思路。现有的机制下，只要媒体文件的路径改了，长毛象就无法自动定位到已清理的外站媒体。如果各服务器的媒体文件都加入了ipfs、缓存外站30d以上或者永久缓存有互动的媒体文件，那么只要该文件的hash记录还在，就能从原站或者有缓存的其他站点找到。即使站点自身的媒体文件彻底灭失，用户找回媒体的可能性和便利性都会大大增加。如果数据库还在的话，重建一大部分的站点媒体文件也是可能的。而且对于寻找旧媒体文件的任务，有一定延时也是可以接受的。长毛象对象存储的特点是大量小文件，自建ipfs能否有效应对是个问题。我简单测试了下，参考 https://docs.ipfs.tech/install/run-ipfs-inside-docker/ 建了个docker。通过docker stats查看，平时CPU有一定占用，长时间运行内存会到500MB。加入约10GB（80k）的文件，最高到1.6GB。重启并运行一段时间后稳定在600MB左右。已加入的文件通过公共网关访问未能直接成功，第一次尝试后过一段时间再访问有时能打开，更换默认的4001端口似乎有一定帮助。另外，也有 https://web3.storage 这类将文件交给服务商，让服务商加入IPFS的服务。但价格相比s3看起来没有优势。网关例：https://cloudflare-ipfs.com/ipfs/QmP16cnDGh1NC6DruajXoWvTwFJhgDCDjMsoStYY7e2iBN顺便一提，对于 Filecoin 这类激励层的设想，我曾抱有实现人人为我、我为人人模式的期待。但目前来看，其挖矿的硬件门槛远超民用级NAS https://lotus.filecoin.io/storage-providers/get-started/hardware-requirements/ ，应该会产生明显的中心化趋势。因此，个人对其前景还是有一定疑问。总的来看，ipfs有望为媒体文件的存储提供一些增益，但暂时还不足以抵消实现中的各种麻烦。期待未来能看到更好方案。
(DIR) Post #ASSTsHoNWEIEZYfEO0 by bgme@bgme.me
2023-02-08T04:28:13Z
0 likes, 0 repeats
@lgE > 现有的机制下，只要媒体文件的路径改了，长毛象就无法自动定位到已清理的外站媒体。这个不必引入IPFS也可以解决，比如说重新拉取嘟文再解析媒体文件地址。> 长毛象对象存储的特点是大量小文件，自建ipfs能否有效应对是个问题。我简单测试了下，参考 https://docs.ipfs.tech/install/run-ipfs-inside-docker/ 建了个docker。通过docker stats查看，平时CPU有一定占用，长时间运行内存会到500MB。加入约10GB（80k）的文件，内存最高到1.6GB。重启并运行一段时间后稳定在600MB左右。你太乐观了，想要保证访问质量（30秒内可达）至少8G内存打底。https://bgme.me/@bgme/109824146741758212图中的情况，还是在没怎么存储文件，也没有什么访问量，更没有调整bitswap参数的情况下。即使这样，图中的那台vps，最后还是因为内存不足整个死机了。反正4G vps 想愉快的运行IPFS节点是很困难的。当然8G是最保守的估计，如果访问量大，内存消耗肯定还要再往上涨，可能要16G、32G。你嘟文链接中的系统需求，不也是要128GB RAM + 128GB swap 吗？TB级别的小文件，至7000-8000个Fediverse Peering，外加终端用户的访问以及IPFS网络内部的交换。想要愉快的运行一个供Mastodon使用的IFPS节点，所需系统资源可能也不比 8Core 128GB RAM 低多少。另外，matrix-media-repo 项目已经计划移除IPFS支持。https://github.com/turt2live/matrix-media-repo
(DIR) Post #ASSUDhMzglSjvC474i by bgme@bgme.me
2023-02-08T04:32:06Z
0 likes, 0 repeats
@lgE > 现有的机制下，只要媒体文件的路径改了，长毛象就无法自动定位到已清理的外站媒体。这个不必引入IPFS也可以解决，比如说重新拉取嘟文再解析媒体文件地址。> 长毛象对象存储的特点是大量小文件，自建ipfs能否有效应对是个问题。我简单测试了下，参考 https://docs.ipfs.tech/install/run-ipfs-inside-docker/ 建了个docker。通过docker stats查看，平时CPU有一定占用，长时间运行内存会到500MB。加入约10GB（80k）的文件，内存最高到1.6GB。重启并运行一段时间后稳定在600MB左右。你太乐观了，想要保证访问质量（30秒内可达）至少8G内存打底。https://bgme.me/@bgme/109824146741758212图中的情况，还是在没怎么存储文件，也没有什么访问量，更没有调整bitswap参数的情况下。即使这样，图中的那台vps，最后还是因为内存不足整个死机了。反正4G vps 想愉快的运行IPFS节点是很困难的。当然8G是最保守的估计，如果访问量大，内存消耗肯定还要再往上涨，可能要16G、32G。你嘟文链接中的系统需求，不也是要128GB RAM + 128GB swap 吗？TB级别的小文件，至7000-8000个Fediverse Peering，外加终端用户的访问以及IPFS网络内部的交换。想要愉快的运行一个供Mastodon使用的IFPS节点，所需系统资源可能也不比 8Core 128GB RAM 低多少。另外，matrix-media-repo 项目已经计划移除IPFS支持。https://github.com/turt2live/matrix-media-repo这也算是他山之石可供参考。此外，由于 docker 对 IPv6 支持很差，对于IPFS这样存在大量P2P通迅的应用，最好让它直接运行在Host中，而不是Docker里。
(DIR) Post #ASSckQgbXS2tMqM9Hk by c@misskey.gothloli.club
2023-02-08T05:52:31.401Z
0 likes, 0 repeats
@bgme@bgme.me @lgE@mstdn.one 另一个站用的ipfs，日访问30w左右，ipfs娘长期吃13g内存（
(DIR) Post #ASSckRCVcpZAxnHd0y by bgme@bgme.me
2023-02-08T06:07:38Z
0 likes, 0 repeats
@c @lgE 另一个站？那个 book search？
(DIR) Post #ASbsfh5Ad4ZGaa8oDI by lgE@mstdn.one
2023-02-12T17:18:28Z
0 likes, 0 repeats
@bgme 如果原站还存在，重新拉取确实是可行的。我这段也没多乐观吧，按10GB 对应 100MB 暴力计算，内存量也挺恐怖的。而且我指的是可以接受延迟的寻找旧媒体任务。128GB RAM + 128GB swap 这个是挖矿程序，不单单是IPFS。docker 想用IPv6，比较简单粗暴的做法就是 --net=host 。对于服务器，配一个静态的 fixed-cidr 也算可以接受。