Linux on 随手记

USB 转 SATA / NVMe 桥接芯片在 Linux 下的兼容性对比

Fri, 22 May 2026 00:00:00 +0800

很多 2.5 寸硬盘盒、M.2 SATA 硬盘盒、M.2 NVMe 硬盘盒看起来只是“USB 外置硬盘”，但真正决定 Linux 体验的，经常是里面那颗 USB 桥接芯片和它的固件。

同一块 SSD，换一个桥接芯片，可能会出现完全不同的结果：一个盒子能跑 UASP、能 fstrim、能读 SMART；另一个盒子只跑 usb-storage，或者大文件写入时反复 USB reset。本文把常见的 ASMedia ASM1153E、JMicron JMS 系列、Realtek RTL 系列放在一起，对 Linux 下的兼容性做一个偏实用的对比。

先给结论

如果只是给 2.5 寸 SATA SSD/HDD 做 USB 外置盒，ASM1153E 和 JMS578 都很常见，也都支持 UASP。ASM1153E 的整体口碑偏稳，但 TRIM/SMART 仍然受固件影响；JMS578 功能完整、价格低、出货量大，但不同固件之间差异明显。

如果是 NVMe 转 USB，JMS583 和 RTL9210/RTL9210B 是常见选择。JMS583 是早期大量普及的 USB 3.1 Gen2 转 NVMe 桥，规格漂亮，但旧固件、散热和某些主机组合下更容易遇到掉盘或重置；RTL9210/RTL9210B 后来在很多硬盘盒里成为更常见的“稳妥选择”，但也不是免疫，仍然要看固件版本和具体硬盘。

Linux 下不要只看商品页写的“支持 UASP / 支持 TRIM”。更可靠的判断顺序是：

USB-SATA 桥接芯片的 UAS 兼容性问题排查

Wed, 20 May 2026 09:30:04 +0800

通过 USB 外接硬盘时，如果遇到磁盘看起来一直很忙，但实际吞吐很低，问题不一定出在文件系统或硬盘本体上。一次比较典型的场景是：USB-SATA 桥接芯片声称支持 UAS，但它的固件实现不稳定，Linux 自动启用 UAS 后反而触发命令超时、USB 设备重置，最终表现成系统层面的 I/O 卡顿。

这篇文章记录一次这类问题的现象、原因和处理方式。

问题现象

故障最直观的表现是：外接硬盘几乎不可用，但监控上又看不出正常的高吞吐。

常见现象包括：

iostat 中磁盘 %util 长时间接近或等于 100%；
实际 r/s、w/s、rkB/s、wkB/s 并不高；
await、svctm 或应用侧读写延迟异常升高；
文件复制、解压、数据库读写、备份任务间歇性卡住；
偶尔出现 Input/output error；
dmesg 或 journalctl -k 中反复出现 UAS abort、SCSI timeout、USB reset。

可以先用下面这些命令观察：

iostat -xz 1

dmesg -T | grep -Ei 'uas|usb|reset|abort|I/O error|blk_update_request'

journalctl -k -b | grep -Ei 'uas|usb|reset|abort|I/O error'

比较典型的内核日志类似这样：

uas_eh_abort_handler ...
scsi host... uas_eh_device_reset_handler
usb ... reset SuperSpeed USB device number ...
blk_update_request: I/O error, dev sdX, sector ...

如果这些日志和外接硬盘卡顿时间点高度重合，就要怀疑 USB 存储协议层的问题。

在 Docker 中部署 mihomo，并让本机与局域网电脑接入

Tue, 19 May 2026 00:00:00 +0800

mihomo 是 Clash.Meta 的延续版本，常见用法是把它作为一个代理内核运行在一台长期在线的机器上，然后让本机、手机、Windows 电脑、Linux 电脑都通过这台机器访问代理服务。

这篇文章记录一个最实用的部署方式：在 Docker 里运行 mihomo，宿主机负责提供端口，局域网里的其他设备只需要把 HTTP / SOCKS 代理指向这台机器即可。

总览：先看整体链路

假设运行 Docker 的机器局域网 IP 是 192.168.1.10，mihomo 在这台机器上监听 7890 端口：

Windows / Linux / 手机
 |
 | HTTP / SOCKS 代理：192.168.1.10:7890
 v
Docker 宿主机：192.168.1.10
 |
 | mihomo 容器
 v
按规则直连或走代理节点

关键点只有三个：

mihomo 配置里开启 allow-lan: true。
mihomo 监听地址使用 bind-address: "*" 或宿主机局域网 IP。
Docker 把 7890 端口暴露给局域网。

第一步：准备目录

在准备用作代理网关的机器上创建目录：

mkdir -p ~/mihomo/config
cd ~/mihomo

后面所有文件都放在 ~/mihomo 目录里：

Docker 日常维护、运行调试与排错教程：从 Compose 到 Swarm

Wed, 29 Apr 2026 16:25:00 +0800

Docker 用久以后，问题通常不在“会不会启动一个容器”，而在日常维护和排错：容器为什么退出、日志在哪里看、端口为什么不通、磁盘为什么爆了、Compose 更新为什么没生效、Swarm 服务为什么一直 Pending。

这篇文章按实际运维顺序整理：先看单机 Docker 的容器、镜像、日志、网络、存储和资源排查，再看 Compose 的项目级管理，最后看 Swarm 的集群级服务维护。

总览：Docker 排错先分清三种运行层级

Docker 相关问题先不要急着敲命令，先判断当前应用跑在哪一层：

层级	常见命令	管理对象	适合场景
单机 Docker	`docker run`、`docker ps`、`docker logs`	container、image、volume、network	单机服务、临时调试、本地开发
Docker Compose	`docker compose up`、`docker compose logs`	一个项目里的多服务	开发环境、小型部署、依赖编排
Docker Swarm	`docker service`、`docker stack`、`docker node`	service、task、stack、node	多节点集群、滚动更新、副本调度

排错时也按这个顺序看：

服务不可用
 -> 容器是否存在、是否在运行
 -> 日志里有没有启动失败或业务异常
 -> 端口映射和网络是否正确
 -> volume、配置、环境变量是否正确
 -> CPU、内存、磁盘是否打满
 -> 如果是 Compose，看 project/service 维度
 -> 如果是 Swarm，看 node/service/task 维度

一、日常巡检：先看 Docker 基本状态

先确认 Docker daemon 是否正常：

Linux 各个目录的作用：从根目录理解系统结构

Tue, 28 Apr 2026 17:53:07 +0800

如果你刚开始接触 Linux，打开终端输入 ls /，会看到一组看起来很固定的目录：bin、etc、home、usr、var、proc、dev 等。它们不是随意命名的文件夹，而是 Linux 系统长期演化出来的一套目录分工。

理解这些目录的作用，有助于你知道配置文件在哪里、日志在哪里、用户数据在哪里、程序通常安装在哪里，也能避免误删系统关键文件。本文会以 Linux 根目录 / 为起点，逐一讲解常见目录的用途。

1. `/`：根目录，所有路径的起点

Linux 的文件系统是一个单一的树状结构，最顶层就是 /，也叫根目录。

无论是系统文件、用户文件、磁盘分区、U 盘、网络挂载目录，最终都会挂载到这棵目录树的某个位置。和 Windows 常见的 C:、D: 盘符不同，Linux 更强调“从 / 开始的一棵树”。

例如：

/etc/ssh/sshd_config
/home/alice/document.txt
/var/log/syslog

这些路径都从 / 开始。

日常使用时，不建议直接在 / 下随意创建文件或目录。根目录通常只放系统约定好的一级目录。

2. `/bin`：基础命令目录

/bin 用来存放系统启动和基本维护所需的常用命令。

常见命令包括：

ls
cp
mv
rm
cat
mkdir
sh

这些命令是系统最基础的工具，即使系统处在较小的维护环境中，也通常需要它们。

在一些现代 Linux 发行版中，/bin 可能只是一个指向 /usr/bin 的符号链接。这是因为许多发行版已经采用了 /usr 合并的目录布局，但从使用者角度看，/bin 仍然可以理解为“基础命令所在的位置”。

3. `/sbin`：系统管理命令目录

/sbin 中通常存放系统管理相关命令，很多命令主要供 root 用户或系统管理员使用。

常见命令包括：

ip
reboot
shutdown
fsck
mount

其中不少命令和系统启动、磁盘检查、网络配置、关机重启有关。

Fail2Ban 工作原理与常用运维操作

Tue, 28 Apr 2026 17:35:00 +0800

Fail2Ban 是 Linux 服务器上很常见的一类安全防护工具，主要用来应对 SSH、Web 登录、邮件服务等场景里的暴力破解和重复异常请求。它不会替代防火墙、密钥登录、最小权限这些基础安全措施，但非常适合做一层自动化封禁：发现某个 IP 在短时间内频繁失败，就把它临时加入黑名单，过一段时间后再自动释放。

这篇记录一下 Fail2Ban 的工作原理、安装和开机启动方式、常用规则配置，以及误封后如何把某个 IP 从黑名单里移出来。

Fail2Ban 的工作原理

Fail2Ban 的核心逻辑可以概括成四步：

监听日志文件或 systemd journal。
用 filter 里的正则表达式匹配失败行为。
在指定时间窗口内统计同一个 IP 的失败次数。
达到阈值后执行 action，把 IP 加入防火墙黑名单。

这里有几个关键概念。

jail

jail 是 Fail2Ban 的规则单元。一个 jail 通常对应一个服务，例如 SSH、Nginx、Postfix、Dovecot 等。每个 jail 会指定：

监控哪个服务。
读取哪个日志。
使用哪个 filter。
允许失败多少次。
统计时间窗口是多少。
封禁多久。
使用什么 action 封禁 IP。

例如 SSH 的 jail 就是监听 SSH 登录日志，匹配登录失败记录，当同一个 IP 在一段时间内失败太多，就通过防火墙封禁。

filter

filter 负责识别“什么日志算失败”。它通常放在：

/etc/fail2ban/filter.d/

例如 SSH 常见 filter 是：