北陌大叔1. 磁盘与权限到底有多重要：一次生产事故给我的教训
先说个我自己的真实经历。几年前我负责的一台业务服务器半夜报警，说是磁盘空间满了，但登录上去用 df -h 一看，使用率只有 62%，怎么看都不像满的样子。可业务接口确实在报错，日志里写的是 "No space left on device"。后来查了半天才发现，是文件系统 inode 耗尽，小文件把索引节点占满了，跟磁盘块剩余多少没关系。那一次折腾到凌晨三点，也让我彻底明白一件事：磁盘系统和权限管理不是"会用几个命令就行"的基础知识，而是任何一个跑着真实业务的系统都绕不开的硬门槛。
这篇内容不是教科书式的命令罗列，而是把我这些年处理磁盘分区、挂载、文件系统选型、权限模型设计、甚至应用层 RBAC 权限控制的实战经验整理成一份可复用的操作笔记。适合三类人看：刚接手服务器运维的初级工程师、自己搭 NAS 或家庭服务器的小白玩家，以及后端开发中需要理解"用户-角色-权限"底层逻辑的软件开发者。
磁盘系统管的是"数据能存多少、存得稳不稳、满了怎么办"，权限管理管的是"谁能读、谁能写、谁能执行、谁能改配置"，两者看似独立，实际在真实项目里经常纠缠在一起：磁盘挂载目录的权限错了，应用就起不来；ACL 配得乱七八糟，数据就被人误删了。所以我把它们放在一起讲，而且重点放在"为什么要这么做"和"踩过的坑长什么样"上。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 磁盘系统整体设计与方案选型
2.1 分区方案设计的底层逻辑：别拿到新盘就一路回车
很多新手拿到一块新硬盘，第一个动作就是整块盘分一个区直接格式化使用。这种操作在个人电脑上问题不大，但在服务器或者数据稍微重要点的场景下，迟早要还债。
分区方案到底怎么定，核心看三个问题：系统盘和数据盘要不要分开、需不需要扩容能力、换系统或者迁移数据时能不能承受把整块盘重新处理的代价。
我的建议是至少把 /、/home 或数据目录、swap 分开。原因很朴素：系统目录单独分区后，即使数据目录被日志或者异常文件写满，操作系统核心功能还能用，你不会因为一个失控的日志文件导致 SSH 都登不进去。swap 单独分区或者单独使用 swapfile，可以在物理内存不足时有一定缓冲，不会让进程直接 OOM 被杀掉。
如果按用途分得更细，比如 /var、/tmp 单独分区，也是常见的做法，尤其是日志密集型的业务，/var/log 写满导致全盘撑爆的情况我见过不止一次。把它们单独分出来，出了问题只用处理对应的分区，不至于整个系统陷入僵局。
提示：分区不是分得越多越好，每个分区都有独立的 inode 和空间上限，如果某个分区空间规划小了，后续扩容反而麻烦。我个人的经验是"按故障域和业务域来分，而不是按目录树结构来分"。
2.2 MBR 与 GPT、fdisk 与 parted 的选型取舍
分区表格式直接决定了单块盘能支持多大容量、能分多少个主分区。MBR 最多支持 4 个主分区，而且是基于 32 位寻址，单块盘 2TB 封顶。GPT 没有这个问题，最大支持到 ZB 级别，而且在现代操作系统的支持度上已经非常成熟了。
我给读者的建议非常直接：2024 年之后的今天，一律用 GPT，不要犹豫。除非你是在维护一台十年前的旧机器并且 BIOS 只支持 MBR 引导，否则没有任何理由再开历史倒车。
分区工具方面，fdisk 和 parted 都能干活，但使用场景不一样。fdisk 对新手更友好，交互式界面一步一步引导，适合快速分一个或几个区。但 fdisk 默认只处理 MBR 分区表，如果要创建 GPT 分区表，老版本需要切换模式，交互方式也比较绕。parted 是命令行一步到位，支持脚本化操作，在批量初始化和自动化场景中更方便。
拿一块全新的 2TB 数据盘举例，用 parted 分区并格式化的完整流程长这样：
bash复制# 查看机器上识别的磁盘设备和盘符
lsblk
# 用 parted 操作 /dev/sdb
parted /dev/sdb
mklabel gpt
mkpart data ext4 0% 100%
align-check optimal 1
quit
# 格式化
mkfs.ext4 /dev/sdb1
align-check optimal 1 这步是检查分区是否对齐。现在大家用的大多是 SSD 或高级格式化硬盘（4K 扇区），分区起始位置不对齐会直接导致随机读写性能明显下降。很多人分完区格式化完根本没想过这件事，结果跑数据库时 latency 一直不对劲，查了半天发现是分区没对齐。
2.3 文件系统选择：ext4、xfs、btrfs 到底怎么选
文件系统的选择要结合业务形态，不能只看"哪个快"就说哪个好。
我自己在服务器上长期用的两个是 ext4 和 xfs。ext4 胜在成熟稳定，几乎任何 Linux 发行版默认支持，出问题时从社区能找到大量现成方案；xfs 在超大文件和大型文件系统上有优势，单文件大小上限极高，而且对并发写入的优化做得更好，很多数据库和大数据组件的官方文档都会推荐把数据目录放在 xfs 上。
btrfs 这些年也成熟了不少，支持快照、压缩、校验和，玩 NAS 或者自建存储服务器的人很爱用，因为可以做子卷和自动快照。但它在大规模生产环境的采用率还是不如 ext4 和 xfs，主要是因为之前出现过若干次坑，团队技术积累不够的情况下不建议贸然用在核心业务上。
再提一个不太起眼但很关键的细节：mkfs.ext4 时有个 -m 参数，默认预留 5% 的块给 root 用户，避免系统关键进程因为磁盘满而无法写入日志。但如果你挂载的是一块 4TB 的数据盘，5% 就是 200G