guochao

存路径这个做法本身有点怪……我可能会选择文件的其他特征来做这个事情……

不清楚场景，假设场景必须要存路径，考虑一下把 SOMEHASH(filepath, account), account 作为 key 呢？比如说 trigger 去 set 一下额外的列为 SHA2(CONCAT(filepath,"\\/", account), 256)，把这个列作为 unique key 的一个 column 。降低碰撞概率的话，多加一种两种哈希呢？

我是写业务的菜鸡，暂时还只能想怎么实现的问题。要不然就只能业务上限制一下了

听歌是为了解决更严重的问题，不解决特定的问题就不需要听歌，比如说噪音、状态引导、blablabla

@gridsah 赞！

> 原理是 OpenZFS 直接和内核里的 NFS 子系统通信
哈，我暂时还没有研究这些。如果是这样的话，其实我就比较倾向直接用 exports ，因为最近非常喜欢 nixos 那种 declarative 的理念，而且这种方法管理的系统很容易统一各种 id ，不过不开心的就是还有很多工具不大好声明式管理，需要写很多足够健壮的脚本

> btrfs 离开群晖之后只能在特定几个版本的 Linux 内核下读数据
群晖用了一些私有的 flag ，是有问题。对于我来说，我更多的是被 arch wiki 里面的警告吓到了：The RAID 5 and RAID 6 modes of Btrfs are fatally flawed 。所以之前尝试 btrfs 的时候，叠了一层 mdadm ，btrfs 跑在单个 md 设备上。

> 快照用的空间被写满
对照了一下使用场景，我的 use case 里面数据大部分时候是增加的，不会有很多改变，所以对于我来说分配好 volume 留出冗余就还好。对于经常有变更的场景感觉是个问题

本地构建以后放到单独的存储里面啊，没必要放到 git 里面，这玩意儿不需要管理版本，只要有一个文件能告诉研发这个构建产物是哪个 reference （ commit/tag ）构建产生的就行。

像是 github 、gitea 、gitlab 、bitbucket 都提供了 repo release 这类功能，就是给你建立一个 release 然后放产物用的。

再不行有个 nfs 、samba 、s3 、nexus 、webdav 什么的都可以放产物嘛。

如果是把 git 当存储，就把构建放到一个单独分支里面。如果存二进制建议再开个 git lfs

不要暴露自己的服务在公网上。

- 建议找个技术向的朋友，或者你自己懂一些 IT 的话，在国内租个最便宜的主机、并且做好安全措施。然后用 headscale ，或者 zerotier-one + 自建的一个发现服务（我不记得是叫 moon 还是什么了）。用这些公网发现、建立点对点的方案。

- 其他的 vpn 服务来建虚拟网络也可以，比如说 cloudflare 这类，但是我自己没有用过，所以我不做评价。
- 直接用 wireguard 也是一个选择，但是自己用服务器中转速度会受限于你的服务器的速度，并且流量可能会计费
- tailscale 、zerotier （公共的发现服务）这类国外的服务，有的时候发现的不是最短的路径，可能会绕很远的一圈。headscale 是 tailscale 的自建服务器，我自己测试是 ok 的，zerotier-one 的 moon 也是类似的东西，我没有正儿八经的配置过。

补充内存计算的问题：java8 用 8u372 及以上版本，修了 cgroup2 支持，这是很多新发行版默认的 cgroup 实现，涉及到内存的限制和计算。

java11 以上可能没这个问题了

Dockerfile 略微注意一下就好了

- 尽量使用多阶段构建，要不然代码拷到 layer 里面了
- 慎用 alpine ，不清楚的时候一律用 debian 作为基础镜像
- 部署环境内核比较新的时候，base 不要使用 centos7 这种带着很老的 glibc 的 image ，java 和库依赖 glibc 的时候，很老的 glibc 在新内核上会有问题

现在 zfs 主要是在 openzfs 上做开发了吧，bsd 那边可能也切过来了？我这两年没有特别多用其他 unix ，不大好横向比较

我的 pc 现在是 nixos root on openzfs ，compression=on ，开 dedup 以后资源消耗有点大，但是我感觉在公司用 xfs vdo 也是有点，后来关掉了，因为发现我的用例来说即使算上 rust / node_modules 实际上好像也没有那么多 duplication 。文件系统自带 samba/nfs 这种感觉有点……奇异。现在处于不停的啃 openzfs 、gentoo 、solaris 之类的文档的状态，打算先在日常使用、变更最多的机器上尝试各种新技术以后再上 nas 。

nas 之前是 btrfs ，但是我心里有点打鼓，尤其是我没有用专门的很好的设备，而是捡了个垃圾，供电什么的都没有那么好。所以也是先换 debian + mdadm + xfs 了，在公司用的多，我自己解决一部分问题，大佬解决一部分问题。btrfs 以后再尝试吧。

比较在意 lvm2 的 snapshot 在什么方面不能满足需求？我自己感觉 lvm2 的 snapshot 一般情况也够用了

truenas core 现在还是 freebsd 吧？我看 truenas scale 是 linux 的样子。以前尝试过 core ，后来没太多用这个。

部署：
> 需要支持服务端 windows/linux/mac/bsd 部署
如果你能搞定不同端 go 的 CI （构建、测试），go 的评分会略微高一些，否则脚本类会好一些。

其他因素：
评分的构成还有你具体的业务，以及你所在的地区不同语言找到能用的人的难易度