Peng Liu's blog

坑边闲话：ZFS 在文件系统层面可以提供许多方法保证数据可靠，但 ZFS 依然受限于硬件损坏的限制。在发生硬盘报错、I/O hang、resilver 卡死等故障时，首要的处理任务是确保系统处于可用状态。如果系统已经被 D 状态进程或错误风暴拖垮，那么任何恢复操作（例如新建池、替换硬盘、执行 zfs 命令）都会极度缓慢甚至完全卡死。 1. 保证系统可用· ZFS 中的 RAIDZ vdev 具有同步 I/O 语义，只要 一块磁盘无响应，整个 vdev 的 I/O 都会停在那里等待，引发： 大量 D 状态进程 命令执行卡住（例如 zpool status、zfs list） resilver / scrub 长时间 0B/s 文件系统操作卡死 CPU soft lockup 这是 ZFS 的一致性设计决定的，但对故障盘来说会让系统被拖死。 因此：第一步永远是 offline 故障磁盘。 什么是 D 进程？ Linux 进程常见的四种运行状态说明如下。 R: 程序正在运行或者是在等待运行的队列中。 S: 处于休眠状态的进程，等待触发事件。 D: 不接受任何异步信号的休眠状态...

坑边闲话：绝大多数人都听过「3-2-1 备份原则」：至少三份数据，存储在两种不同介质上，其中一份存放在异地。然而，即使在真正理解这一原则的人群中，数据丢失的案例依然层出不穷。原因很简单：他们只有备份意识，却没有备份系统；只有备份习惯，却没有自动化策略。本文以 ZFS 为底层文件系统，讲解备份过程中的内功心法。如果你使用的是其他类型的 CoW 文件系统如 BtrFS，应该也能从中获益。 现实中最危险的情况并不是“没有备份”，而是： “我打算做备份，但还没开始。” “我上个月备份过一次，应该没问题。” “我桌面同步到 NAS 了，也算备份吧？” “我准备找时间再备一下。” 一旦出现硬盘损坏、系统崩溃、勒索病毒、用户误删，手动备份都是苍白无力的。只有当备份方案具备以下特征时，数据才真正安全： 自动化：不依赖人的意志； 低开销：不打扰日常工作，不占用过多资源； 可验证：快照、校验机制确保备份有效； 可逆转：恢复流程清晰，不需要人临时拼命抢救。 换句话说： 可靠的备份不是“记得备份”， 而是“就算你忘了，系统也会替你记得”。 1. 备份的内功心法· 本来笔者打算花大量篇幅介...

坑边闲话：最近看评论区，发现有些人严重误解我的观点，他们认为我宣传「用了 ZFS 就无须 ECC」。当推断出这个意思的时候，我感觉很震惊。因为我自认我是一个 ECC 鼓吹党，下这个结论自然是有违初心。既然谈到了 ECC 必要性，那我就尝试讲一讲我的选择逻辑。 1. 永远都有信息不对称· 主题先写在开头：当你不懂时，“买最贵”不是炫富，而是承认信息不对称。 这篇文章想讲清楚一件常被嘲笑、却在工程和生活中反复奏效的事：对于我不懂的东西，买最贵的（或至少买最好的）往往是王道；而现实更残酷的一点在于，当你不懂行时，你通常缺乏经验性地判断何为质量最好的能力，于是所谓“买最好的”很容易沦为一句口号，最后能真正落地执行的往往只剩下一个可操作的替代指标：买最贵的，因为在一个相对成熟、竞争充分的市场里，“最好的往往最贵”不是逻辑必然，却确实是一个依概率成立的真理，它像一条粗糙的上界约束，帮助我们在知识盲区里把失败概率压下来。 这里先给“买最贵”洗个冤：它不是要宣称价格等于价值，更不是在鼓励消费主义；它更像一种决策策略：当你无法有效评估质量、无法建立测试体系、也无法承受频繁试错时，你就不得不承认...

坑边闲话：ZFS 是一个多功能的存储栈解决方案，作为经典的一站式本地存储系统解决方案，它必然不可能被人轻松掌握。精进技能需要长久学习和思考，以及亲自上手对真实应用场景做细致的优化测试。此前有 UP 主在 B 站批评 ZFS 无法做到开箱即用，这主要是因为他们对 ZFS 不够了解，正所谓「难者不会，会者不难」，沟通的鸿沟就在这里。在复杂的 ZFS 存储优化中，最容易上手并取得巨大收益的一项参数是 recordsize, 特别是在数据库应用场景中，不同的 recordsize 会带来巨大的性能差异。 1. 数据库页面大小检查指南· 核心目标是让数据库的 page_size 等于 ZFS 数据集的 recordsize. 为什么要这么做呢？因为数据库只是文件系统上的一个 file，但是在这个 file 内部，数据库程序会将其划分为不同的 page，数据库程序发起 I/O 的时候，以 page 的大小为基本单位。如果 page 远远小于 recordsize, 如 page_size, 4KiB, recordsize, 128KiB, 那么数据库读取一个 page，ZFS 就...

坑边闲话：最近正值双十一，关于淘宝超高并发的数据库大家可能都有所耳闻。数据库作为现代软件工业中最重要的技术，其蕴含的技术难度可谓是相当大。从关系型数据库的数学原理，到各种高级的数据结构，再到复杂的缓存优化，它们无不向 IT 从业者时刻展示这项技术的光辉与荣耀。本文创作于笔者给本地数据库进行升级、迁移的过程中，这或许并不是一个最佳实践，但我相信这篇文章肯定可以告诉你许多不为人知的数据库秘密。 1. 常见数据库· 1.1 PostgreSQL· PostgreSQL 是一个开源、稳定且功能极其强大的关系型数据库，被誉为「世界上最先进的开源数据库」。它支持标准 SQL，同时提供丰富的扩展能力，例如 JSON、地理空间数据、全文检索和用户自定义函数。许多企业级产品，包括 GitLab、Mattermost、维基媒体后台，都在使用 PostgreSQL 作为核心数据库。它在可靠性、一致性和复杂查询优化方面表现突出，非常适合中大型业务系统以及对数据完整性要求极高的场景。 PostgreSQL 每年发布一个主版本（如 15、16、17），节奏固定且透明。每个主版本在发布后会提供 至少 5...

坑边闲话：最近飞牛发布了一款名为 FnTermX 的应用，允许用户在 web 桌面里使用 SSH，这想法真是棒极了！TrueNAS 的模型就比较粗糙，从 SSH 界面切换到别的界面再切回来，刚才的 SSH 会话就没了。飞牛的设计基于窗口，因此可以长期保活。然而，在反向代理情况下，FnTermX 打开就是一片空白，这到底是为什么？本文尝试简单分析问题的原因，以及分享笔者关于未来的一些构想。 1. 问题归因· 目前在飞牛 web 桌面里，有两套开发桌面 app 的方案： 基于 absolute flex 飞牛自研框架，典型 App 包括「文件管理」、「日志」、「系统设置」等原生应用。 基于 iframe 的嵌入型窗口 App，如「百度网盘飞牛版」、「Docker容器管理」。 前者就是最原生的应用，体验最好，兼容性无敌。 后者就是把一个独立的应用加载成飞牛桌面里的小窗口。下面简单展示一下： 通过你的飞牛地址（域名、IP均可）加上路径 /apps/docker 就能直接打开容器管理界面。同样，这也适合飞牛版百度网盘（地址是 IP_ADDR/app-baidu-netdisk/）...

坑边闲话：容器技术是存储、网络、计算的集合体。换言之，要想使用好容器，需要对容器的存储、网络、计算模型有比较丰富的经验。本文介绍在 Linux 系统上部署多个容器服务时可以使用的方案。 1. 思考几个问题· 首先，在单机部署十几个乃至数十个容器之前，我们先考虑一下有可能遇到的问题。 容器本质上就是服务，服务的存储该如何组织，实现安全、高吞吐、低延迟。 如何组织网络才能使网络架构更简单易用？ 如果容器需要较为稳定的性能发挥，应该如何设置 CPU / GPU 资源？ 2. 应对方案· 2.1 存储性能· 现在大部分容器都使用数据库技术，数据库和普通存储不一样。一般来说，数据库处于文件系统和应用程序之间。 数据库会向文件系统申请较大的单一文件存储自己的所有表。因此数据库的存储粒度是「自行管理」的。虽然看上去 .db 文件很大，但是数据库操作基本上也是小粒度的随机 I/O. 如果底层文件系统的逻辑块大小非常大，每次数据库读写的时候将会带来极大的写放大效应。因此，数据库的底层 I/O 应当和 MP4/MKV 等影音类型有所区别。 如果数据库的 recordsize 被设置的很大，...

坑边闲话：​最近发现还有几个小伙伴看我好几年前的 IPv6 系列教程，虽然为这些内容依然有价值感到高兴，但是以我现在的观点看，用纯 IPv6 还是有些局限性。 用 IPv6 的用户主要是追求网络可达性，这是新人小白网络探索的第一步，毕竟我当你也是这么走过来的。IPv6 的确是很多人刚入门时的「第一道成就感关卡」： 开通之后立刻可以直接发布服务，不需要 NAT； ping6 能通，感觉自由之门已开。 然而这只是网络可达性阶段。 真正的下一步是网络可控性：你要开始关心自己的流量路径、DNS 解析、MTU、路由策略、透明代理、出口策略路由等。 在这个阶段，IPv6 的优势反而变成负担，因为它的机制（NDP、RA、SLAAC、DHCPv6、两套 DNS、甚至双栈回退逻辑）让控制权被分散。 IPv4 加隧道工具的组合 (WireGuard、Tailscale、Cloudflare Tunnel、Zerotier、EdgeOne Connector) 反而让网络拓扑更统一、可控性更强。而且现在跟几年前不同，最近几年的云管理模式的组网工具越来越多，EdgeOne 和 Cloudflar...

坑边闲话：在当今的数据中心和个人计算领域，NVMe（Non-Volatile Memory Express）固态硬盘已经成为高性能存储的事实标准。作为一种基于 PCIe 接口的存储协议，NVMe 相比传统的 SATA 接口提供了更低的延迟、更高的带宽和更强的并发性能。然而，要充分发挥 NVMe 设备的潜力，管理和监控这些设备变得至关重要。这就是 nvme-cli 发挥作用的地方。 1. nvme-cli 的诞生与发展· nvme-cli 是一个专为 Linux 系统设计的开源 NVMe 管理命令行工具，最初由 Keith Busch（当时就职于 Intel）在 2014-2015 年创建并维护至今。Keith Busch 是 Linux NVMe 驱动开发的核心人物，他不仅开发了内核驱动，还创建了这个用户空间工具来管理 NVMe 设备。 项目托管在 GitHub 上的 linux-nvme 组织下（https://github.com/linux-nvme/nvme-cli），采用 GPLv2 许可证。多年来，这个项目得到了来自 Intel、三星、Western Digita...

坑边闲话：早年笔者一直以为网盘只能通过官方客户端使用，然而官方客户端并不好用。最近一两年，网盘的本地挂载越发成熟，海内外的网盘公司纷纷推出 OpenAPI，允许第三方开发者使用网盘。将 OpenAPI 和 libfuse/winfsp 结合起来就可以实现网盘的本地挂载，基本可以像操作本地文件一样操作网盘里的数据，特别是在只读场景。本文详细介绍商业软件 CloudDrive2 的使用方法。 1. 安装与配置· CloudDrive2 是一个以网盘本地挂载为卖点的商业软件，虽然目前还处于 0.x 版本，但它已经有了很强的可用性，而且在笔者半年的使用时长中表现非常稳定。 不过要注意，并非所有网盘都支持本地挂载，也并非所有网盘都提供 Open API 允许开发者折腾。比如知名的百度网盘就没有 Open API, 现有的挂载功能基于对百度网盘的协议逆向。 1.1 Windows 与 macOS· Windows 需要打开 19798 端口的防火墙入站。对于 macOS，需要进入 Recovery 模式，临时关闭 SIP 以安装 macFUSE，随后即可重新启用 SIP. Windows...

坑边闲话：前面的文章提到，群晖使用 Synology 认证硬盘是出于对家用市场的轻视，以及对企业级市场的向往。然而半年的时间刚过去，群晖就决定在 DSM 7.3 里移除这个限制。笔者审阅了群晖 7.3 的发布公告，并没有明确看到取消硬盘认证限制的说明，但是 GURU3d 声称群晖确实悄咪咪地移出了限制。 1. 现状分析· 消息源自 GURU3D 现在的市场对于群晖可能比较严苛。 AI 数据中心的崛起导致 HDD 出货集中在 DC 领域，NAS 家用市场的配额明显变变少，进一步拉低用户购买 NAS 的意愿。 中国大陆出现了很多 NAS 竞争对手，包括绿联、飞牛在内的 NAS 系统基本把群晖的 web Desktop 功能复刻了一遍，群晖独有的用户体验已经不再是护城河。 与中国大陆的友商相比，群晖的价格过于昂贵。 现在群晖头铁还要给自己加限制，基本等同于放弃了中国大陆市场。群晖高层可能是观望了半年，最终决定取消限制。不过这也从侧面印证，群晖的家用市场收入依然在总收入中占据很大一块，企业级的收入尚且无法让群晖放弃家用市场。 其实不仅仅是群晖，Qnap 如今也在逐渐放低姿态，使用...

坑边闲话：Jellyfin 作为一个开源免费且声誉良好的媒体服务器一直被玩家追捧，然而 Jellyfin 早期与 SQlite 绑定非常深，导致无法丝滑迁移到其他的高级数据库。在数据非常多且数据库查询插入操作很频繁的情况下，SQlite 显现出了巨大的弊端。 哔哩哔哩原文 此前我 follow 这个版本已经很久了，终于，等到了正式版。 Jellyfin 脱胎于 Emby，因此前期的很多代码与 Emby 重复很多，不过这些陈年历史就不讲了。下面单纯围绕媒体服务器的一些特点进行讲解。 此前 Jellyfin 使用的后端数据库是 sqlite，这是一个超级强大的本地数据库，据说其源代码的测试框架有 9000 多万行代码（仅仅是为了测试 sqlite），基本实现了百分百代码覆盖率测试。 然而 sqlite 有个致命问题，那就是无法扩展。注意，不是扩展很难，而且没有任何办法横向扩展。因为 sqlite 基于单个文件。一旦某个进程占有了这个数据库文件并上锁，别人就没办法使用这个数据库。 可怕的是前期的 Jellyfin 完全基于 sqlite 开发，换言之，你的电影元数据、演员元数...

坑边闲话：ZFS 要发挥出最好的性能，离不开专家优化。本文介绍 ZFS 在资源充足情况下的优化方式。 哔哩哔哩原文 1. NVMe 阵列要配置强大的多核 CPU· ZFS 目前的物理磁盘块分配模型与 NVMe 多队列、队列深的特性不能兼容，因此丑话说在前面：CPU 一般的情况下，很难把 ZFS RAID-Z 的性能优化到特别强，比如发挥出 PCI e 4.0 x4 ZFS member 50% 性能。 NVMe 协议与 CPU 核心的环形队列机制密切相关。它通过 SQ 和 CQ 实现主机与控制器间的高效通信，每个队列为环形结构，可绑定到特定 CPU 核心。环形缓冲区的特点就是能减少锁竞争与中断延迟，实现多核并行 I/O 处理。然而，NVMe 软阵列性能依赖 CPU 多核并行处理能力。每个 NVMe 队列通常绑定一个核心，负责提交与完成 I/O，核心数量太少会导致多个设备和队列争夺同一核心资源，产生上下文切换和中断延迟，无法大规模并行处理请求，最终使 IOPS、带宽显著下降，阵列性能受限。 如图1所示，EPYC 7302 这种弱鸡的胶水核心，最多也就能发挥出一个 Gen4 ...

坑边闲话：B 站后台提示我成为 UP 主已经 1999 天了。如果加上我第一个视频的制作筹备时间，总天数已经达到 2000 天。这不仅是一个数字，更是一段旅程的长度。在这 2000 天里，我从一个技术爱好者成长为一个内容创作者，也经历了热情、倦怠和反思。我用这段时间记录了我的技术学习之路，也收获了很多同行、朋友和灵感。这篇文章，也是一封写给所有关注我的人尤其是老观众的信。今天，我终于做出了一个重要的决定——开启频道付费。 1. 为什么选择内容付费模式· 首先声明，我的所有付费视频会根据时长、实效性等因素设置限时免费观看，一般是发布后的 24 到 120 小时。我想如此久的免费限时观看足够大部分网友看完我的最新视频。毕竟，我不希望内容付费成为一道墙，而是成为一座桥，用来连接我和那些认可我的人。 如果你不希望错过某些精彩内容，点击关注并打开内容更新提醒将是非常明智的选择。 1.2 为优质内容付费是时代的共识· 如果一个视频能够让你对某项技术有更深的洞察，或者直接帮助你优化工作流，我想大多数人都会愿意主动打赏：少则点赞投币，多则充电支持。 别人怎么想我不确定，但我自己确实是这样做...

坑边闲话：本文首发于哔哩哔哩专栏。OWC 一直深耕专业工作室领域，推出过不少很有价值的雷电扩展坞，比如采用 Intel JHL7440 芯片的 Thunderbolt Pro Dock 给我留下了深刻的印象。如今 OWC 沿用相似的外观设计，推出了一款支持双万兆电口的雷电 5 扩展坞。 哔哩哔哩原文 OWC，型号：Thunderbolt 5 Dual 10GbE Network Dock 官网地址 看名字就知道，有两个 10GbE 万兆接口，竟然还都是电口！ 后置的两个 10GbE 网口彼此独立，均采用 AQC113 方案，支持 IEEE 802.1Qav，也就是一种为 audio/video 优化过的 QoS，保证音视频流的实时性。这个功能在 2.5G 网口上是不支持的。 此外这个扩展坞砍掉了 CF-express 接口，导致小工作室拷卡颇为难受。不过专业剧组为了防止素材流出，一般都会对原始素材上锁，只允许专业 DIT 拷贝并加密存储在 NAS 上，一般剪辑师只能远程挂载代理媒体进行剪辑，不允许直接访问原始素材。因此，在剪辑机上用 CF-express 烤卡也显得不...

坑边闲话：Linux 的系统初始化教程对新手非常有帮助，本文提供一个合适的流程化操作，方便用户使用相关服务。本文遵循最小化安装原则，帮助用户逐步构建自己的 Linux 系统。所谓最小化安装，指的是不添加过多的 package，只包含最基本的系统组件。当然，也不包括图形化界面。 前期必看步骤：使用 ZFSBootMenu 安装 Linux 重装前先备份 若用户是重装系统，请务必记得备份重要数据，比如 zsh 历史记录 ~/.config/zsh/.zhistory systemd 的自定义条目，如 多容器组合启动服务 harbor.service, minio.service ZFS 定期快照任务 zfs_snapshot.service /etc/fstab 的特殊挂载条目 家目录中的工程项目 某些特殊的、只存储在本地的容器镜像孤本 1. 配置常规用户· 遵照 使用 ZFSBootMenu 安装 Linux 指导安装的用户，可以直接跳到本章最后一节，此前的步骤已经轻松地完成了前面的这些内容。 1.1 创建新用户· 最小化安装之后，系统里仅有 root 用户，因此先...

坑边闲话：感觉 27 岁之后，明显感觉到时间加快，Debian 12 还没用多久，Debian 13 就要出来了。截至笔者编辑这篇文章，Debian 13 已经更新挺长一阵子了。时光易逝，劝君惜取少年时！ 哔哩哔哩原文 Debian 13 镜像发布了！ 有没有提前升级的小白鼠出来介绍一下经验，没有坑的话我也要升级了！ 2023 年的时候升级 bookworm 还是很顺利的，这次据说 bookworm 升 trixie 有 OpenSSH 问题，如果不希望通过 stable-updates 升级 openssh，就只能等 12.12 版本修复问题之后再升级。 另外，trixie 的 tmp 目录默认使用 tmpfs，也就是拿内存的一部分来做存储，以后跑网络文件协议测速可方便了，直接 NFS/SMB 共享 tmp 目录即可，无需使用第三方软件创建内存盘。不过据说默认使用一半内存做 tmpfs，感觉有点激进了，另外不知道会不会和 ZFS 的 ARC 产生冲突。 好消息是 systemd 继续一往无前，吃掉了自动发现和挂载加密文件系统的功能。 这次升级过后，网络接口的名称可能会有...

坑边闲话：在 Linux 集群中，NFS 文件共享协议非常重要。NFS 集访问控制和高性能 RPC 于一身，具有非常强大的实用性。本文详细介绍 NFS 的配置。 1. NFS 的诞生与发展简史· 1.1 NFS 简史· NFS 由 Sun Microsystems 于 1984 年创建，它是一种允许不同计算机通过网络共享和访问文件的分布式文件系统协议。最初 NFS 旨在解决跨异构系统的文件共享问题，允许用户像访问本地文件一样访问远程文件。如今 NFS 是 Unix 和 Linux 领域最常用的共享文件系统，几乎没有之一。 1.2 NFS 与 SMB 的区别· NFS 与 Samba/SMB/CIFS 最大的区别在于设计目标与应用场景。NFS 起源于类 Unix 系统，强调轻量、高效、无状态，适合 Linux/Unix 服务器之间的文件共享。比如，修改了服务器的导出表之后无需重启 NFS 服务器进程即可生效。而 SMB/CIFS 则源自 Windows 生态，功能更丰富（如权限继承、打印共享、用户认证），但协议更复杂、开销也更大，一般用在企业内部员工管理中。 在纯 Linux...

坑边闲话：virtiofs 释放了 virtio 思想的潜力，让 host 和 guest 之间共享文件系统成为可能。此前的操作要么依赖网络，要么使用块设备，都算不上很优雅。前者带来了巨大的网络开销，后者不够灵活。virtiofs 可以在一定程度上缓解这个问题。 哔哩哔哩原文 1. 虚拟化的优化无处不在· virtio 这个思想在虚拟化里简直就是大杀四方，无往而不利。 最近我也几乎是重写了之前的一篇虚拟化博客，感兴趣的朋友可以看一下，里面总结了我最近几年学习使用虚拟化的一些心得、感想。 2. virtiofs 是什么？· 首先说，这是一个基于 FUSE/Winfsp 的文件系统，也就是说，这个文件系统在用户态实现。 它能做什么呢？简单说来，就是绕过网络协议，直接让 host 将自己的文件系统暴露给 guest，guest 可以直接读写主机的某个文件目录。 这看上去非常不可思议，有点类似容器技术里的路径映射，因为它充分利用了主机和虚拟机的存储相邻特性。 由于使用了 FUSE 协议，因此 virtiofs 天生就是一个客户端/服务器系统，需要在虚拟机里安装一个 fuse 模块...

坑边闲话：iSCSI 块共享协议在数据中心里应用非常广泛，但是许多 NAS 玩家只会在群晖、TrueNAS 等系统上使用 GUI 进行配置。其实在标准的通用 Linux 上配置 iSCSI server 非常简单，理解了原理之后，配置所需的实际步骤非常少。本文详细介绍如何在 Debian 12 系统上配置 iSCSI target. iSCSI 服务端被称为 target，在 Linux 生态中有不同的 target 代码实现，本文推荐使用现代内核支持的 LIO（Linux-IO Target），这是官方主流方案，稳定、灵活、内核级支持。 常见 target 不同实现的特性如下表所示。 实现方式 服务名称 管理工具 备注 LIO (Linux-IO Target) 内核模块，服务名 rtslib-fb-targetctl targetcli / targetcli-fb 默认、内核集成、现代系统首选 TGT (SCSI Target Framework) tgt 服务 tgtadm, tgt-admin 老牌项目，用户态，简单轻量，但不再积极维护 SCS...

坑边闲话：作为一个理工男，设计一个吸引人的封面真是太难了。毕竟理工男有自己的审美，能表现出信息是第一位的，吸引人可能只是其次。没办法，审美这种东西和选择无关，而是根植于内心的倾向。 哔哩哔哩原文 左上角是我的频道内部编号，因为以后有可能发布到其他视频平台，B站也不一定能过审，所以就做一个统一编号。以后群友针对某个视频进行提问，直接引用这个编号即可。 右上角是具体的视频类型，比如，存储大类有很多小类，其中包括FileSystem, RAID, Benchmark, SSD 等。 中间是title，表示视频主题。 主题下面是subtitle，视频副标题，一般是我的个人评价。 左下角是关键字列表，比如涉及的产品名及型号，使用的软件及版本号。 为了方便观看，封面底色代表对应的主题。 目前就想到这么多，欢迎B友们补充，好的话我会发小红包感谢。 哦对了，不要告诉我视频索引号和某岛国动作片风格类似 😅 可不是开玩笑的。 还要说一下，在简单的工作场景下，苹果的 Pixelmator Pro 真的可以平替 Photoshop 了，价格便宜而且体验非常不错 👍

坑边闲话：在家用场景下，用户的硬盘规格可能比较杂，不同容量的磁盘组件 RAID，会被木桶原理限制。AnyRAID 是一个新兴的技术，可以在保障安全的情况下最大限度地发挥磁盘的空间。 哔哩哔哩原文 ​在看近期的 TrueNAS Tech Talk 时，我本想了解一下 AnyRAID 的最新进展，没想到看到 Kris Moore 也认同不要使用同一个制造商的同批次产品，因为这样会导致磨损过于均衡。 广告 这里打一个免费的广告。Subeasy 是一个支持多国语言的字幕生成工具，基于 Whisper 大语言模型。 它可以在理解视频音频的基础之上生成字幕。由于大模型能理解故事背景，因此生成的字幕非常准确，很多术语也能较好地翻译。目前它两种模式，第一种是上传音视频文件然后转译字幕，另一种是直接粘贴流媒体网站的视频链接然后由服务器进行下载并处理。后者用来看外文内容非常好用，因为 Subeasy 的翻译功能基于大模型，所以翻译质量非常高。 目前该网站对免费用户有每天有一次的快速处理，以及另外两次的慢速通道处理。 对于自媒体博主，只要粉丝量在5000以上就可以申请激活码，免费获得一个月的无...

坑边闲话：本文最早发布于哔哩哔哩专栏。复盘做视频这 5 年，发现早期有些视频工程找不回来了。仿佛失去了很多东西，像是一个孩子在春天的田野里想抓住空中的飞虫，然而伴随着夕阳的落下，那些错过的信息彻底沉默在了时间的长河里。 哔哩哔哩原文 起这个标题并没有耸人听闻的意义。 目前经过我细致的排查，总共有三成的视频失去了原始素材。少数几个存有素材，但是失去了工程文件，还有一部分貌似保留了一部分原始素材。 统计完数据，感觉心好痛。 后来又找到了一个，53/181=29% 损失惨重。其中有我精心制作的几个我本人非常看重的视频，还有播放量最高的几个视频。 目前来看，丢失的素材有以下几种： 整个素材、工程彻底找不到了。 部分素材还能找到，但是有一些素材丢了，比如在 DaVinci Resolve 中录制的音频片段随着重装软件、系统而丢失。 还能找回素材，但是工程文件丢了，因为剪辑工程比较复杂，因此无法还原当时的剪辑状态。 还能找回素材，工程文件也丢了，但是工程非常简单，甚至没有几笔剪辑，可以较为轻松地恢复工程。 1. 为什么会丢失数据呢？· 怎么还有些 2024 年的素材也丢了...

坑边闲话：在关闭多线程之后，采用本地测试的方式，笔者发现 ZFS 呈现出了惊人的 NAND 直读、直写性能。本文介绍这一发现，但并不尝试分析原因。 哔哩哔哩原文 最近在跑实验，supervisor 建议我关闭超线程。找了半天 BIOS 没找到 HyperThreading 选项，最后发现 AMD 的超线程不叫 HT, 而是 SMT. 遗憾的是 SMT 的关闭与 performance tuning 的关闭是绑定的，所以 NUMA per socket 就得手动设置，最大一个 CPU 插槽 4 个 NUMA，对应两个 ZEN3 CCD. 毕竟 EPYC 7003 内部就是四组内存控制器，这很合理。 有意思的来了。 我看到核心连线的拓扑图，发现设置了 NPS 之后，CPU 与 NVMe 的关系变得更具体了，说人话就是 NVMe 与 CPU 的亲和性更高了。于是我顺手给这个 ZFS 跑了个分。 服务器：H3C R4950g5 with dual AMD EPYC 7763 zpool 包含两个 vdev 第一个是四盘 intel 750 1.2TB MLC raid-z1 ...

坑边闲话：在上文中，笔者介绍了 Docker 的一些常识和基本命令，并对新手朋友做了友好的介绍。容器作为云计算的底层技术，在存储、网络、计算方面都必须足够完备。上文仅介绍了容器镜像的组成以及如何使用容器进行服务、计算。本文将以 Docker 作为案例，对容器的网络模型进行细致分析。 1. Docker 简介· 如果我们把容器想象成一个虚拟机，那么它本身将有一套完整的网络协议栈和网络硬件。换言之，容器有自己的网卡、IP 地址、传输端口。然而真实的容器并不是虚拟机的替代品。 容器常识 目前容器技术有两个方向： 进程级容器，比如 Docker. Docker 于 2013 年 3 月首次发布，推动了容器技术的标准化发展，并最终促成了 OCI（Open Container Initiative）标准的建立。目前，Docker 及其兼容实现已成为进程级容器的主流。 系统级容器，比如 LXC. LXC（Linux Containers）诞生于 2008 年 6 月，早于 Docker. 该技术由 IBM 最初开发，旨在作为虚拟机的一种轻量级替代方案。它更强调运行一个完整的 Linux ...