博客

这个是我自己的备注，如果有后续的话，再在这个上面修改。

最早使用的是自带的win11,偶尔掉，或者隔断时间掉，因为懒，所以没理会。

后来突然系统的ssd固态挂了，重新安装的时候，就安装了win10,比win11太香了，win11我记得跑鲁大师好像90万+,win10能跑130万+，刚开始不怎么掉。

最近突然掉的非常频繁，用着用着突然发现点击没用了，然后接下来黑屏，虽然最后还是能回来，但比较烦人了。之前网上提到的改65W模式，改系统电源模式 之类的，在之前使用过程中也做个相应测试，总是没啥用。

因为太影响使用了，比如我开个win10的命令行终端（就是那个支持多标签的），一打开就黑屏，还没输入几个字符又黑屏，实在忍无可忍了，就汇总了下之前的各种尝试。

最大的可能原因是电源问题，但作为小主机，这个没办法改变，无论是修改电源哦是还是改高性能模式，都是为了加大供电。我突然想到修改显存的地方，默认的好像是分配4G显存 （记不清楚了），里面有个游戏优化模式，既然是游戏优化，自然是增加gpu供电了，于是修改为这个模式。之后启动后，正常使用就没有掉驱动了。

只所以说正常启动，是因为我是终端的铁粉用户，我只要打开终端，就会掉驱动，只是频率也比之前的低了些而已。于是，我就翻了下终端的配置，里面有个“图形api”的选择， 默认是自动的，我就将其修改为”Direct3D 11″了，之后就没掉驱动了。

我自己觉得，总的而言，还是GPU部分的供电引起的，可能现在的各种软硬件优化，尽可能的提高能耗效率，造成当gpu突然执行某个高功耗的流程的时候，电力就瞬间跟不上了。

修改后到目前为止，还没发生掉驱动。因为这台电脑不是主力工作机，只是在家里偶尔使用下，所以还有待观察。

PS： 很多次掉驱动的时候，再回来都提示阿里云盘的程序出错了。为啥阿里云盘在后台无任何任务也需要gpu运算，我也不太理解这点。

我的一个私人邮箱是使用mailu自建的，mailu的resolver使用的是unbound来做解析的。 之前用的unraid，接收邮件没问题，unraid这边的docker版本是24， 现在使用自定义的 iso镜像，结果发现无法接收邮件了，就是无论是从哪个邮箱中发给它，都会被退信。

刚开始我以为是fail2ban拦截的事情，结果把fail2ban关闭了之后依旧。我也怀疑过smtp服务器 的问题，但看了半天没研究个明白。后来看到部分日志说对方域名无法解析，于是就试着在smtp容器中 解析域名，查到最后发现unbound所在的地址（默认的192.168.203.254），根本就无法收到， 虽然该地址可以ping，但貌似53端口被docker拦截了。然后发现如果smtp容器中的dns服务器配置为 外部的之后，邮件就收到了。所以最终的原因是unbound容器无法提供服务引起的。

比较奇怪的是，即使我在unbound容器中使用容器地址进行dns解析，依然会无法连接。这真是个 奇怪的问题。先把所有的解析修改为主机的，回头再研究docker的这个奇怪的问题，或许iptable可以 看出端倪？

ubuntu 24.04 lts发布支持bcachefs，因此这段时间试用了下bcachefs文件系统，发现还很不完善。

1. ubuntu 24.04 的内核6.8相比最新的bcachefs版本老旧很多，不过，相比最新的版本，似乎读写速度要快不少（越开发效率越低了）。 最初安装的时候，使用的是自带的，虽然老，但一晚上复制文件也近2T了（1X128G SSD+3x256G SSD+2X2T HDD+1X3T HDD）。然后发现一个不知道是 bcachefs的bug(我更倾向于bcachefs)还是linux的bug,发现磁盘的uuid丢失了。也就是有应用覆盖了磁盘上不该覆盖的位置。至此，我 突然明白了unraid系统的分区会先在磁盘上创建一个分区的好处了。正好我自定义的live iso构建好了，鉴于ubuntu的太老，就直接测试用新的了。
2. 使用新的后才发现，读写速度大幅下降，比原来慢了至少3倍左右，本来就不如btrfs，结果更慢了。我使用的代码是非常非常新的（2024-12-11的版本）。 可能开发者一直在忙于解bug和完善新特性，总之，非常慢，如果ubuntu 24.04 lts还将就可用的话，那这个版本就非常不可用。举几个一点都不夸张的例子：
   1. rsync 复制文件长时间在10MB左右（这还是在我将副本数量设置为1的前提下了）
   2. rm 删除一个2T的目录大约需要10-20分钟左右
   3. device evacuate 一个256的固态ssd, 用了近2个小时
   4. 如果前端和后端存储采用的压缩算法不一样，比如前端不压缩，后端压缩，在存储快满的情况下（大约85-90%左右），会不断的触发平衡，导致ssd进行大量的 读写操作，ssd的寿命快速缩减。在过去的一周内，我的一块固态的剩余寿命大约降低了10% （48%->37%），用于测试固态寿命这块，效率还不错。
3. 虚拟机的磁盘文件如果在bcachefs上，运行速度会非常的慢。是真的很慢，win7关机都需要几分钟那种（即使是ubuntu 24.04 lts的版本也如此）。
4. 我比较喜欢的bcachefs的特性主要是可以不用大小的磁盘配合使用（btrfs也可以, zfs不可以）, 可以使用ssd做磁盘缓存(btrfs不可以),这样，我手边的存储可以 尽可能的有效利用。
5. 目前，我还在不断的测试中，但已决定不做主要用途了，等性能优化差不多再做体验吧。

之前不使用校验，而是btrfs的raid10,但存储减半了，而我的数据很快的达到了存储上限，于是，又折腾回带校验的了。 可能我的硬盘真的比较老了，或者金手指氧化之类的，总之，在安稳运行了接近3个月的时候，在每个月初的磁盘检查（含校验）的时候， 又一块硬盘可能被断电重置之类的，出现了错误丢失了（硬盘的设备号变了，由sde变为了sdn）,然后校验就暂停了。

我手动挂载了一下有故障的硬盘，可以挂载，各数据也正常。还是将其中重要的数据备份了下，这块盘存储绝大部分数据都不重要。

这个时候，我有两个选择，一个重新生成配置，这样重新校验。另外一个是使用校验盘来重建这块盘上的数据。鉴于之前填的unraid的坑， 以及未验证的测试。我决定冒险重建一下这块盘上的数据，毕竟这就是使用校验盘的作用。

通过将该硬盘的位置设置为无配置，启动阵列，然后停止阵列，重新配置该硬盘，然后启动阵列，unraid开始进行重建了。阵列列表中， 提示该硬盘无法挂载。 最下面，提示是否格式化，这个时候千万不能格式化。然后有重建的进度提示等。

经过长达12个小时的重建，unraid提示重建完成。但这个硬盘还是无法挂载。搞不明白为什么，重新启动阵列依然无法挂载。这就很莫名了， 这个重建的含义在什么地方。现在只有一个格式化的选项了。

由此来看，我最初就选了一个错误的选择。

反正这块硬盘上的数据已经完全被重新了，我就点了格式化，于是这块硬盘数据就全没了。（这里我应该单独挂载一下这块硬盘，然后试下btrfs的修复功能的，这么好的机会）

反思：

unraid的校验盘我一直对其定位比较迷茫，我认为这个校验盘就是为了保全数据的，为此按照官方的建议，每隔一段时间就进行重建。 但从几次出现故障的处理过程中来看，有太多的限制。

1. 校验进行过程中不能有磁盘错误，否则可能会引起后续的重建失败，这个也可能是概率问题。但校验盘的目的是为啥呢。
2. 如果硬盘的质量很好，逻辑错误应该也会写入到校验盘中的，这时候重建自然会出问题，如果没错误用校验的目的为啥呢，就为了某次添加硬盘或者更换硬盘的时候重建一下，复制数据可能会更快吧
3. 无论是添加还是要重建，都需要重启阵列的。使用raid的目的，首先是为了高可用性。使用校验盘，在磁盘出现错误而又可能重建失败的情况下，其作用就不明确了，还浪费了 磁盘寿命，消耗了电力，拖慢了读写速度。
4. 如果校验盘起不到相应的功能，对我自己而言，使用其他的linux发行版可能更合适，扩展性更强，数据的保护可能会更好。理性的考虑一下，如果不依赖校验，自己会做更多的定时备份，数据检查， 如果数据出现问题，也会尽可能多的保全数据，而校验盘的存在，则将所有的依靠都放到了数据校验修复这一不靠谱的操作上了，毕竟不是谁手边都随时备着几块闲置无数据的硬盘。
5. 回头还是老老实实的使用其他的linux服务器版本，自己维护数据吧。在我使用unraid 的这几年，尽管都是些不重要的数据，但也陆续丢了不少数据了，相比之前的十多年数据维护，还是手动的 放心些。

android手机改直供电后，电量还一直在缓慢下降。

  adb shell dumpsys battery  set status 2 #改为充电模式
adb shell  dumpsys battery set level 98 #设置电池电量