Post AUGeRoPnB1ptt7LTMG by mashiro@hello.2heng.xin
(DIR) More posts by mashiro@hello.2heng.xin
(DIR) Post #AUGeRoPnB1ptt7LTMG by mashiro@hello.2heng.xin
2023-04-03T07:14:23Z
0 likes, 0 repeats
mastodon（或者说gem paperclip）一个恶心的地方是储存媒体文件时要把activity record id拆分成了一大串子目录：如图1的文件，其原本的id是104530971904218116，最后被拆成了104/530/971/904/218/116 （：id_partition部分）我想不出这样设计有什么意义，但是最终的结果是list对象储存时会产生大量性格最贵的C类请求。misskey是将所有文件储存在根目录，list n个文件产生n次C类请求，这是最理想的情况，但是同样的n个文件mastodon要产生n*(6+2)次C类请求，+2是因为104/530/971/904/218/116 下面还有original和small两个子文件夹。打算趁这次重构的机会把这个地方改一下，直接把所有内容写在文件名上不就行了：':prefix_url:class/:attachment/:id_partition/:style/:filename' -> ':prefix_url:class/:attachment/:id-:style-:filename'
(DIR) Post #AUGfHUBjcmLuDLPUH2 by fivestone@mastodon.fivest.one
2023-04-03T07:23:20Z
0 likes, 0 repeats
@mashiro 一些文件系统譬如 freebsd 的 ufs，仍然有单个目录下不超过 32767 or 65535 个文件之类的限制。所以大概是为了确保兼容性？以及即使是不限文件个数的系统，感觉单个目录文件多到一定程度后，对文件系统的开销，可能并不比C类请求低……
(DIR) Post #AUGfdEZQN8GA9ArRLc by mashiro@hello.2heng.xin
2023-04-03T07:27:39Z
0 likes, 0 repeats
@fivestone 有道理，这确实是本地fs应该考虑的问题。不过目前我所有文件都是直接保存到s3上的，fs性能应该不需要我考虑了吧😂
(DIR) Post #AUGfizH09we8RPzGhE by fivestone@mastodon.fivest.one
2023-04-03T07:28:41Z
0 likes, 0 repeats
@mashiro 嗯，虽然我的 s3 也是自己建的……
(DIR) Post #AUGfsLYmfPUqAWlewC by xtexChooser@neko.ci
2023-04-03T07:22:47.368Z
0 likes, 0 repeats
@mashiro@hello.2heng.xin COS当存储服务器给我的感觉就是有钱（似乎在本地文件系统使用的时候这样拆分成树状目录可以稍微提升一点访问速度？（毕竟是在树上搜索
(DIR) Post #AUGfsMaaqAXPMQccOe by mashiro@hello.2heng.xin
2023-04-03T07:30:22Z
0 likes, 0 repeats
@xtexChooser 其实cos是是目前相对便宜的解决方案，下载流量我是通过一台内网服务器代理的，实际成本就是每月十来块的储存和请求费用
(DIR) Post #AUGftvIXHOjHIVv4DY by mashiro@hello.2heng.xin
2023-04-03T07:30:41Z
0 likes, 0 repeats
@fivestone minio嘛？
(DIR) Post #AUGfwz3XlNdDp2MmEC by mashiro@hello.2heng.xin
2023-04-03T07:31:13Z
0 likes, 0 repeats
@fivestone 我硬盘可没那么大，你用的是minio嘛？
(DIR) Post #AUGg3Fp8KoF3YzcGH2 by xtexChooser@neko.ci
2023-04-03T07:31:26.150Z
0 likes, 0 repeats
@mashiro@hello.2heng.xin 也许可以试试用caddy或者nginx之类反代一下解决URL问题（x
(DIR) Post #AUGg3GOaD0b9KwCZWq by mashiro@hello.2heng.xin
2023-04-03T07:32:21Z
0 likes, 0 repeats
@xtexChooser 等改了路径以后我是打算用nginx重定向旧文件的
(DIR) Post #AUGg8pxFQcJt4M4cxU by fivestone@mastodon.fivest.one
2023-04-03T07:33:20Z
0 likes, 0 repeats
@mashiro 是啊，我实例小，vps 200g 够用了。甚至再买一个 200g 做分布式，都比 scaleway 划算……
(DIR) Post #AUGgUi11ct3KokGn6e by mashiro@hello.2heng.xin
2023-04-03T07:37:19Z
0 likes, 0 repeats
@fivestone 我打算用backblaze b2，应该是全网最便宜了 :ac_classic01:
(DIR) Post #AUGgq0YfscI2PMAIoi by error@m-i.im
2023-04-03T07:41:09Z
0 likes, 0 repeats
@mashiro @fivestone 我比较过了，idrive e2最便宜。我正在使用，不过我首月账单还没来。
(DIR) Post #AUGziShJGzpiUcJsEy by PRCCWS@hello.2heng.xin
2023-04-03T11:12:42Z
0 likes, 0 repeats
@mashiro 虽然听不懂但是站长棒棒 :siamese_014:
(DIR) Post #AUICUGThOwsd6QTQvI by akiyamamizuki@nightcord.de
2023-04-04T01:10:28Z
0 likes, 0 repeats
@mashiro 感觉这玩意跟QQ聊天图片缓存一个b逻辑，导致后期索引起来特别特别慢。
(DIR) Post #AUJNTBARPA7uySZDo8 by winguse@m.wingu.se
2023-04-04T14:38:12Z
0 likes, 1 repeats
@mashiro 一时间没找到之前看的一篇文章，不过保持一个目录下面的文件数量小于256（或者附近）是可以让这个目录只需要一个独立的 iNode 不用扩展。而大多数时候，磁盘上的 inode 访问后会缓存在内存，速度非常快。
(DIR) Post #AUL1xWMkNMTgKlk4Se by lgE@mstdn.one
2023-04-05T09:56:38Z
0 likes, 0 repeats
@mashiro 个人觉得还有一个问题是 cache 和 local 媒体混在一起，如果能分别设置存储，甚至于只是分离在两个文件夹也会好很多
(DIR) Post #AULAhxKRGCaCuaJbW4 by mashiro@hello.2heng.xin
2023-04-05T11:34:42Z
0 likes, 0 repeats
@lgE 目前是分开的，缓存的远程文件都应该在cache目录下
(DIR) Post #AULDfK7QN2QwaUfF8y by lgE@mstdn.one
2023-04-05T12:07:49Z
0 likes, 0 repeats
@mashiro 我觉得理想的配置是/local/accounts/...和/cache/accounts/...。现在根目录一个accounts/加上cache/accounts/，导致写本地备份不是那么方便，要枚举或者排除（有软件排除的运行效率很低）。更方便的就是我之前说的，如果能分别设置存储，一个local一个s3，或者是不同的s3桶，那就更理想了。
(DIR) Post #AULJLZilFfeQuV5vqy by lgE@mstdn.one
2023-04-05T13:11:28Z
0 likes, 0 repeats
@mashiro media_attachments/thumbnails/ 有些是来自外站然后在本地生成的文件我说的分开配置是/local/accounts/...和/cache/accounts/...。现在根目录一个accounts/加上cache/accounts/，导致写本地备份的程序不是那么方便，要枚举或者排除（有软件排除的运行效率很低）。更方便的就是我之前说的，分别设置存储，一个local一个s3，或者是不同的s3桶。搜了搜，看来有人提过 https://github.com/mastodon/mastodon/issues/12382。
(DIR) Post #AULMTiJRUYZbjgpB2m by lgE@mstdn.one
2023-04-05T13:46:34Z
0 likes, 0 repeats
@mashiro prefix这么复杂可能也与s3性能有关：https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html
(DIR) Post #AULMvoGqvtZGK70hrE by mashiro@hello.2heng.xin
2023-04-05T13:51:40Z
0 likes, 0 repeats
@lgE 懂了，要实现是可以的，不过我估计这种需求除非有现成的pr，否则G大是不会花精力去做的
(DIR) Post #AUMbYP3gCOlHwF6boG by mashiro@hello.2heng.xin
2023-04-06T04:10:13Z
0 likes, 0 repeats
@lgE 我原来还以为s3服务商会自动帮我们做prefix优化 :ac_classic54:
(DIR) Post #AV7hxGrE4BfCML9B0C by coelacanthus@mastodon.yuuta.moe
2023-04-28T21:33:20Z
1 likes, 0 repeats
@mashiro 在一些文件系统上如果单个目录条目过多会导致性能暴跌，此外另一个问题就是目录条目数量上限。它的主要问题是没有给不同的储存后端设计不同的访问和储存方式。