首先 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 我甚至开测试仓库

太酷辣

systemd 就是大而全，contab 是小而美。用哪个自古以来就是一个争议话题。我的意见是，如果任务简单就使用 contab ，如果任务可能超时、需要依赖其他组件、有特定启动顺序、需要自动重试之类就用 systemd

@kyonn 是的，让 chatgpt 给你写个 fastapi 接收 “webhook 或特定格式的输入”然后用 apprise 发送

apprise

sqlite 文档 FAQ 里就写道

“Threads are evil. Avoid them. ”

sqlite 没有并发，一切写入都是单线程。如果你硬是开多线程那么之后造成互相竞争锁更慢

koreader

mdbook 然后往什么 github pages 之类的免费平台一挂就完事了

猫好，夸夸

photoprism 不是支持 heic 吗，元数据也能读

window.mycache ={}
你在制造原本就不存在的问题

这个是 sway 桌面的配置文件，位置在家目录的 .config/sway/config

效果如图 https://a.yongyuancv.cn/ipfs/QmS6VUxCWyB1Dc6SyUXdFkznnYP6pNvdCfuz1TVQVQ81ov

wayland 下用 sway 很容易做

```
# Main monitor
output DP-1 {
pos 0,0
mode 1920x1080
}
workspace 1 output DP-1

# VNC monitor on iPad
output HEADLESS-1 {
pos 0,1080
mode 1024x768
}
workspace 2 output HEADLESS-1
```

然后开启 vnc `wayvnc --output=HEADLESS-1 -r -g <你的内网 IP> 5900`

应该吐嘈 javascript 框架