heimoshuiyu

golang 吉祥物好看吗

@Moonkin 并不是“大部分人都喜欢有人工管理的社区”。我觉得只是在“严格审查的大规模社区”和“没人管的孤独模拟器”之间找到一个平衡点

@aloxaf 缓存问题你说的对，但我指的是在有写缓存的方案之上创建 btrfs 或 zfs ，上层的文件系统调用 fsync()写入数据时，下层的写缓存设备在数据实际写入磁盘之前就向文件系统报告已经写入完成，并且可能改变实际的写入顺序。这相当于破坏了日志文件系统的一致性

noatime 我开了，数据库目录我也 +C 了，btrfs defrag 有一些改善，但不多，现在想也可能是因为我元数据用 raid1c3 的原因（

在 btrfs raid1 模式下，文件被分成多个片段，每个片段写入到任意两个设备中，不管池里有多少设备，如果写入分布均匀，同时坏两块盘，那么几乎可以肯定会有数据和它的副本位于这两块坏盘上，这些数据就损坏了。也就是说，btrfs raid1 只能容忍坏两块盘，坏两块盘必丢数据，数据很有可能分布在各个文件中，盘越多风险越高

@Moonkin 每个 instance 的管理员当然能能管理自建的实例，在他的 instance 上他想干什么都可以。实例规则只是君子协定。如果你想保证没有人能删帖那么最好自建实例，然后用过直接关注或者中继到其他实例，别人除了 block 没有任何办法。

第一条不熟悉，不清楚。

第二条，我也是这样，但是我发现我有一个显示器（ HDMI 接口）即使关掉了（但不断电）系统也会认为它还连接着。我就可以放心关掉显示器并使用远程。或者干脆插个显示诱骗器在显卡上。

fediverse

首先 btrfs 就有点灵车属性，把 btrfs 放在任何方案之上都是灵上加灵，灵车漂移。数据损坏不是丢几天数据这么简单的问题，如果硬件或其他故障，缓存里的数据不一定能写回 btrfs ，可能破坏 btrfs 元数据，导致整个文件系统出问题。

zfs 资源消耗大是事实，但 op 有 64G 内存我认为是资源充裕。我在树莓派和系统盘上使用 btrfs ，在 32G 内存的 nas 上使用 zfs 。

我的 nas 曾经是 4x4T 的 btrfs raid1 ，小文件比较多，ls 一个 10000+文件的目录需要 5 秒以上，sqlite3 数据库经常需要 30s 写一个 transaction 。迁移到 zfs 后这些问题都不存在。要说性能下降，btrfs 比 zfs 更严重。

没有 ECC 使用任何文件系统的风险是一样的，zfs 没有什么特殊的地方。

op 有 4 个盘，考虑到 btrfs raid5/6 是灵车，只能用 raid1 。btrfs raid1 的意思是吧数据块放在任意两个设备上，那么 4 块盘坏任意两块就会导致 **全部** 数据丢失。而且目前 btrfs raid1 没有实现读取的加速，读取是根据 pid 数字选择设备，除非你有多进程，否则读取就是单盘的速度。

综上，简单需求 / 资源受限 / 设备大小不一致或者未来会经常增减设备 的情况下才考虑使用 btrfs

debian 我甚至开测试仓库

太酷辣