只要你完全不用国内 APP 的话，问题应该不大。

一般来说，内地行货的手机系统（包括外国品牌的国行）都对国产 APP 进行了优化，能镇得住。
所以哪怕用一个国产主流 APP ，都可能会遇到国际版系统镇不住的情况，你需要自己 Hack 处理。
比如要买东西装个淘宝，国际版系统大概率续航会显著下降。

另外上架 Play Store 的国产 APP 不多，有的上架了也是功能阉割版（对一些人来说是好事，对另一些人来说反而不方便）。

先看看啥错误，能不能修复。

然后看能不能用 logrotate 自动处理一下，比如只保留 100M 。

@sldaniel #89 我是打算一个 ATX 电源同时带主机和硬盘笼，目前接了主板、CPU 、显卡、风扇的供电，硬盘笼就是再来三个大 4Pin （硬盘笼背板）和一个 SATA （给风扇 hub ），我看了看我的电源剩下的接口是够的。

@xinmans unraid 整个都是以它的 array 为核心来设计的，unraid 引入的 zfs 也是被当做 array 的缓存池来设计的，只不过你可以不将数据 move 到 array 里，来当成普通 zfs 阵列用，只是按照我上面介绍的目录用途，你要按照 unraid 的设计来使用 mnt 下的目录。
zfs 池被 unraid 定位为缓存池，所以你仍然只能在 array 启动的情况下使用 unraid 的 zfs 池，配置共享目录的第一存储为 zfs 池，然后数据就都是在/mnt/cache 里了。
如果你在 vm 里直通硬盘组 zfs 阵列，那么你就不应该把 zfs 阵列挂载到 unraid 的任何挂载点里，以免造成两个系统之间的冲突，比如你可以在 mnt 下单独创建个目录用来放虚拟机创建的 zfs 阵列的挂载点。

@sldaniel 哦对了，硬盘笼就是个笼子+背板，HBA 卡也是要主板上至少一个 pcie x8 通道，板 U 还是要自备。
如果不要额外配板 U 的那种应该就是阵列柜，一般都很贵。

@sldaniel 我就是打算用浪潮拆机电子垃圾……
m4 硬盘笼深度尺寸小一些，用 12G 转 6G 的线可以插 6G 的 2308HBA 卡，散热可以整个 m4 硬盘笼尺寸的亚克力风扇架套在后面，硬盘笼一般是 3 个 D 型 4pin 供电，风扇可以用个 hub 拿一个 sata 供电带起来，对我来说电源除了带主机现有供电以外，带笼子供电口还是很够的。
至于显示，因为我要跑视频转码，所以肯定有 GPU ，就不需要借助亮机卡了。

以上方案调研了有半个月，还没正式尝试，现在是在等其他配件到位。

@TNOK #36 因为我自己是 DIY 的 NAS ，所以我现在逢人都推荐买品牌 NAS……

NAS 本身绝对是个很氪金的坑，省心、省钱不可兼得。

@TNOK #21 一般品牌 NAS 都有自家的扩展机，外接的第三方硬盘盒/硬盘柜可能可以用，但大概率没法纳入到 NAS 系统本身的管理体系，顶多也就是临时倒腾数据用。

你用品牌 NAS 还是建议攒钱买品牌自家的扩展机，或者直接换更多盘位的产品。

DIY 的 NAS 一般没这种限制，像我用 OMV 和 unRIAD 都是可以将外接硬盘盒/硬盘柜纳入到自己的硬盘管理体系的。

不过不管怎么说，有 USB 本身的可靠性和速度方面的局限，一般也不推荐长期使用。
我是 DIY 的，也是四盘位，容量撑了四五年，现在不够用了接了一个 USB 硬盘盒；计划整一套 HBA 卡+硬盘笼，用一个 PCIe x8 接口换 12 个能跑满机械盘的盘位，把硬盘都转移到硬盘笼里。

我个人当面试官的时候是不在乎学历的，但是如果简历多了 HR 会拿一些硬性指标强行筛掉一部分简历，首当其冲的就是学历。

另外就是一些不懂技术的单位在招聘技术人员的时候，因为自己没办法判断人员技术能力，所以只能通过学历之类的条件硬性筛选。

如果你刚参加工作，或没什么人脉和口碑，学历就是个有用的敲门砖。等你工作了几年，发展出了好的人脉和口碑，就主要走内推介绍了。

RAID 主要是用来保障可用性的，就是有盘坏了系统不会立马挂掉；不保障完整性，要想保障数据完整性还是得备份。

看你描述不知道你到底认为要存的数据重不重要，虽然“没什么重要的”但是“不想炸盘了全没了”，姑且认为你觉得数据重要，那就多冗余（至少两块盘冗余）或者备份（哪怕只备份你觉得真的重要的那部分）。

但你 NAS 的这个盘位又很尴尬，4 盘位组 RAID-6 （或同类方案）冗余度和 RAID-10 一样，都是只有一半空间可用。要不你换个更多盘的 NAS 或者 USB 接几个硬盘盒？

RAID-5 十分不推荐，特别是你单盘容量很大，一旦有一块盘故障了买新盘重建要花很长时间，时间越长挂掉第二块盘的概率越大，然后数据就全部丢失。同生产批次的硬盘寿命相近，也会增加多块盘同时坏的概率。

要是想要安全可以不用 RAID ，用 JBOD （或同类）方案，比如开源免费的 MergerFS+SnapRAID ，以及闭源收费的 unRAID Array 。这类方案的好处是文件不会被拆分成条带分散到多快盘里，一个文件会完整存在于一个盘里，哪怕把单块盘直接拔下来插到其他电脑上也可以正常当单块硬盘读取文件。这样一来即便磁盘盘片有了一部分灾难性损伤，只要其他部分在维修车间可以读出数据，就也能有很大希望将部分文件抢救回来。但缺点就是没有 RAID 的速度加成，最快也就是单盘速度，像 unRAID 如果开启了校验盘速度会更慢。不过用来看电影，单盘的几十兆到一百兆的速度应该也够用了。

我是使用 Unassigned Devices 这个插件来管理 array 和 pool 之外的存储设备的，支持自动挂载，挂载之后会在/mnt/disks 下有一个挂载入口，通常是以硬盘名称命名（自己可以改）。

如果容器、虚拟机、脚本啥的要访问这个存储设备，直接让它访问/mnt/disks/下的这个挂载入口就行。

如果想在 WebUI 上查看和操作文件，可以在主界面的 Disk Devices 板块里直接点击这个硬盘 Identification 一列的挂载点名称就可以。或者使用 Dynamix File Manager 插件直接访问 disks/挂载点。再或者用 docker 部署 File Browser 并将/mnt/user 和/mnt/disks/设备名全挂载到容器里。

如果想将这个硬盘通过 smb 或 nfs 共享到网络上，可以在 设置->未分配的设备（ Unassigned Devices ） 中开启 smb 或 nfs ，再在主界面的 Disk Devices 板块里的 设置 一列点选这个硬盘，在里面开启 共享。

有个这个教程详细讲述了 unraid 的/mnt 下面各个目录的作用 https://www.jackiewu.top/article/unraid-storage-mount-point-explanation
如果自己 hack 的话，也最好根据 unraid 的使用范式来使用或规避，避免冲突。

先看是不是在保修期内，如果是的话找售后处理。

这种就是事实上已经开始出现鼓掌了，但是在使用备用方案来尽可能延续可用性，一般如果资金预算不是很紧的话，建议换成新盘，或者当存放非重要数据的临时盘。

以下是个人的一些理解：
酒在酿造过程中，发酵越彻底、酒精浓度越高、糖分越少，否则相反。生活中会使用“干”和“甜”来描述这种发酵程度，越“干”表示酒精浓度越高、甜味越少（留下的就是酸涩），越“甜”就代表酒精浓度越低、甜味越多（除了那些高度数再加糖的酒）。

可能是因为更流行陈酿风味，也可能是因为易于保存，人们普遍喜欢“干”葡萄酒，比如干红、干白。所以市面上看到最多的是干型葡萄酒。但对于没有喝葡萄酒习惯的人来说，对葡萄酒本身的风味不是那么敏感，但对味觉上的感受会更敏感，所以这些人对干型葡萄酒的酸涩味的感受盖过了对风味的感受。

我就属于以上描述的这种人。

葡萄酒也有甜型酒，比如甜红、甜白，可以试一试。

说道其他果酒，我喝过意大利的 Limoncello （柠檬酒），虽然不是纯柠檬酿造的，甚至是用酒精调制的，但个人比较喜欢它的味道，感兴趣可以试一试。

/mnt/user 是 array+缓存池的聚合目录，/mnt/cache 是纯缓存池的目录，/mnt/user0 是纯 array 的目录。

unraid 有个 mover 机制，就是定时移动文件，从 array 移动到缓存池或者从缓存池移动到 array 可以自己在共享设置里面调，比如从缓存池移动到 array ，就是 mover 执行完之后/mnt/cache 里没有被占用的文件都会被移动到/mnt/user0 里。

不清楚你具体说的错乱指的是啥问题。

我基本是直接扔有害垃圾的分类垃圾桶，社区里有俩，公司里也有。

docker 有必要学，其他的了解，等用到了在学也可以

VPN/代理的老本行。

如果你平时手机等其他设备出国，可以让家里当中转，路由配置一下家里的网段直接转发不走机场，这样你公网只需要开放一个代理端口就行了。

建议环境变量不放在 Git 项目里。
我们团队几年前做过一次安全治理，环境变量里大多是数据库、中间件之类的连接地址和访问凭据，为了避免隔三差五被人误发到公共 git repo 上去，要求仅负责部署的运维人员可以看到，所以全部信息都从 git 项目里剥离，并重置所有认证信息。这样使用云原生部署的话可以使用配置中心或者 k8s 的 secret 机制来比较方便和安全地管理。

只要不放在 git 项目里，那么几个分支就是可以互相合并的了。而且可以追踪每个 feature 是什么时候、什么人开发、合并到测试分支、合并到生产分支上的。

如果按照你们的使用方式，你可以使用 rebase 将一个 feature 里的所有提交合并成一个提交，再 cherry-pick 到下游分支上，就是这种做法因为没有记录 merge 操作，所以三个分支之间没有联系，你需要自己去比对 commit message ，同时因为使用了 rebase 合并了提交，导致开发过程中的提交历史细节被丢弃。

Iceraven/Firefox ，手机端可以用扩展。

有些 Crome only 的页面还是得用 Chrome 内核的浏览器，比如一些云文档。

用着顺手就行，不同人需求可能不一样。