存储介质：HDD 与 SSD#

HDD（机械硬盘） 依靠旋转盘片和磁头存取数据。连续读写时磁头移动较少，顺序吞吐较好；大量分散的小请求会增加寻道和旋转等待。它通常适合容量需求大、随机访问要求相对低的场景。

SSD（固态硬盘） 通常使用 NAND 闪存，没有机械寻道过程，随机访问延迟通常更低。控制器负责管理闪存空间和写入回收。

SSD 不等于 NVMe：SSD 可以通过 SATA、SAS 或 PCIe 等方式连接。比较性能时也不能只看标称顺序读写速度，还要看请求大小、读写比例、队列深度和持续负载表现。

命令集、协议与主机控制器接口#

命令集规定“可以请求设备做什么”，例如读写、刷新缓存和查询状态；协议还规定请求与完成信息如何交换。主机控制器接口则解决驱动如何操作控制器的问题。

常见的本地 NVMe SSD 通过 PCIe 连接，但 NVMe 并不只支持 PCIe。NVM Express 规范还定义了 RDMA、TCP 等传输方式，因此“NVMe 设备”不必然意味着“插在本机 PCIe 插槽中的设备”。

ATA、SCSI 和 NVMe 的历史与覆盖范围不同。这里按使用时需要判断的问题区分角色，而不是把每套规范都当成只属于某一层。SCSI 架构与 SAS 标准可从 T10 技术委员会查阅。

总线与互连：SATA、SAS、PCIe#

SATA、SAS 规范本身覆盖多个层面，因此称它们为“存储接口标准”或“存储互连”更准确；PCIe 是通用互连，不是某一种硬盘协议。PCIe 设备还要核对插槽实际提供的代际与通道数，例如物理上能安装，不代表一定能以设备最高带宽运行。

SAS 控制器通常可以接入 SATA 盘，但仍要确认控制器和背板支持；SATA 控制器不能因此反过来使用 SAS 盘。双端口、多路径和热插拔也需要设备、背板、控制器与软件共同支持，不能仅凭名称推断。

外形规格与连接器#

**外形规格（form factor）**描述尺寸、安装方式等约束，连接器关系到触点、电气连接和机械配合。它们与设备使用的协议有关联，但不是一一对应。

例如，M.2 2280 表示常见的 22 mm × 80 mm 卡尺寸，不能据此判断设备采用 SATA 还是 NVMe。键位可以排除部分不兼容组合，但最终应以设备和主板手册为准。SATA-IO 的 M.2 说明也明确指出，M.2 卡形与连接器规格可以承载 SATA、PCIe 等不同接口。

把几个维度组合起来#

这也解释了为什么两块外形相同的 SSD 可能无法互换，而使用相同协议的 SSD 又可能拥有完全不同的外观。

设备名称表示什么#

块设备向上提供按逻辑块地址访问的存储空间。设备文件是访问入口，其名称并不能完整描述后面的物理结构。

设备枚举顺序可能改变。持久挂载通常使用文件系统 UUID；定位物理设备还应结合序列号、WWN、控制器槽位和 /dev/disk/by-id/ 等信息。

用 lsblk 建立设备地图#

1
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
2
lsblk -d -o NAME,SIZE,MODEL,SERIAL,TRAN,ROTA
3
lsblk -f

第一条命令可能得到：

1
NAME                 SIZE TYPE FSTYPE      MOUNTPOINTS
2
sdb                  100G disk
3
└─sdb1               100G part LVM2_member
4
  └─vgdata-lvdata      80G lvm  xfs         /data

这里 sdb1 被 LVM 使用，真正承载 XFS 的是 vgdata-lvdata。不能对 sdb1 再执行格式化，否则会覆盖下层元数据。

TRAN 是系统报告的传输类型，ROTA 表示设备报告的旋转属性；虚拟设备、USB 桥接或硬件 RAID 可能隐藏或改写这些信息。字段为空或 ROTA=0 都不足以证明底层硬件的完整情况。较旧版本若不支持 MOUNTPOINTS，可使用 MOUNTPOINT 并配合 findmnt。

补充确认分区与标识#

1
sudo fdisk -l /dev/sdb
2
sudo blkid /dev/sdb1
3
sudo wipefs --no-act /dev/sdb

fdisk -l 查看分区布局；blkid 识别文件系统等元数据；wipefs --no-act 只列出可识别签名，不擦除数据。签名检查没有结果，也不能证明设备从未使用或没有需要保留的数据。

字段含义及设备关系的显示限制见 lsblk(8)。

分区不等于文件系统#

分区是在块设备上划出的地址范围；分区表记录这些范围的位置、大小和类型。一个分区可以承载文件系统、交换空间、LVM PV 或 RAID 成员元数据。

例如，parted 创建分区时指定 xfs，并不代表已经创建 XFS。创建文件系统还需要单独执行 mkfs.xfs。整盘也可以直接用于文件系统或 LVM，并不是必须分区。

MBR 与 GPT#

GPT 常见默认分区项数量是 128，但并非其不可改变的理论上限。磁盘容量显示还涉及单位差异：厂商的 TB 通常按十进制计算，TiB 按二进制计算。¹

UEFI 与 EFI 系统分区#

UEFI 是固件接口规范，GPT 是分区表方案，二者不是同一种事物。现代 Linux 安装常使用 UEFI 与 GPT，但不要把这种常见组合理解为所有环境下的绝对绑定。

UEFI 启动通常通过 **EFI 系统分区（ESP）**中的 EFI 程序加载引导器。常见 Linux 安装使用 FAT32 格式的 ESP，挂载到 /boot/efi 或 /efi；它与保存系统文件的根文件系统不同，/boot 也不一定就是 ESP。

可以检查 /sys/firmware/efi 是否存在，辅助判断当前系统是否通过 UEFI 启动；容器内看到的结果不能替代宿主机检查。普通数据盘的分区和挂载通常无须修改 ESP。规范定义见 UEFI Specifications。

硬件 RAID 与 Linux 软件 RAID#

硬件 RAID由专用控制器管理成员盘，通常向 Linux 暴露一个或多个逻辑盘。lsblk 无法代替控制器管理工具：成员盘状态、槽位、缓存保护和重建进度需要用厂商工具检查。

Linux 软件 RAID通常由内核 MD 驱动实现，使用 mdadm 管理。成员设备可以是整盘或分区，阵列设备例如 /dev/md0。它可以直接承载文件系统，也可以成为 LVM 的下层设备。

RAID 0：条带化#

数据按条带分散到多个成员，多个设备可以并行处理请求。例如两个成员分别保存数据块 A1、A3 和 A2、A4。

RAID 0 没有镜像或校验冗余。任一成员失效都可能使整个文件系统不可用，适合可以重建的临时数据，不适合作为需要容错的数据存储。性能收益取决于负载和实现，不能保证简单地按磁盘数量倍增。

RAID 1：镜像#

同一份数据保存在多个成员上。常见的双盘镜像中，两块 1 TB 的盘提供约 1 TB 阵列容量，可容忍其中一块盘故障。

镜像便于理解，常用于系统盘或容量较小的重要数据卷。读取可能受益于多成员调度，写入需要维护各个副本；镜像数量越多，可用容量比例越低。

RAID 5：分布式单校验#

数据与一份校验信息分布在成员上，通常至少需要三块盘，可容忍一块成员盘故障。等容量成员的近似可用容量为 (N - 1) × S。

小块随机写可能涉及旧数据、旧校验的读取和更新；全条带写的处理方式不同。重建还会读取其余成员并占用 I/O 资源，因此选型不能只看容量利用率，也要考虑重建期间的性能和再次故障风险。

RAID 6：分布式双校验#

RAID 6 使用两份独立校验信息，通常至少需要四块盘，可容忍任意两块成员盘故障。等容量成员的近似可用容量为 (N - 2) × S。

相比 RAID 5，它在重建期间保留更多容错余量，但也需要更多校验空间和写入处理。具体性能仍取决于实现、缓存和工作负载。

RAID 10：镜像与条带化#

常见的四盘 RAID 10 先组成两个双盘镜像组，再在镜像组之间条带化：

1
                   条带化
2
                /          \
3
          镜像组 A          镜像组 B
4
          磁盘 1、2         磁盘 3、4

这种布局通常提供总容量的约一半。它保证能容忍任意一块盘故障；多盘同时故障能否继续工作，取决于是否仍为每份数据保留至少一个有效副本。例如磁盘 1 和 3 同时失效仍可能工作，磁盘 1 和 2 同时失效则会丢失镜像组 A。

RAID 10 常用于随机读写较多、同时需要冗余的场景。Linux MD RAID10 还有不同布局，不能把四盘双镜像的结论不加条件地套到所有实现。

容量与容错对比#

下表假设成员健康且容量相同，N 为成员数、S 为单盘容量；忽略元数据开销，热备盘不计入可用容量。RAID 1 按双盘镜像、RAID 10 按常见偶数盘双副本布局比较。

RAID 保护的边界

RAID 主要应对成员设备故障，无法保留被误删或覆盖的数据，也无法替代独立备份。热备盘可以缩短开始重建前的等待，但不代表重建已经完成，更不会改变阵列原有的校验级别。

查看阵列状态#

1
cat /proc/mdstat
2
sudo mdadm --detail /dev/md0

双盘 RAID 1 的 /proc/mdstat 中，[UU] 通常表示两个成员都在；[U_] 表示缺少一个成员。还需要结合 mdadm --detail 的阵列状态、活动成员、失败成员和重建进度判断。

看到 degraded 时，先确认故障成员与物理槽位的对应关系、其余成员健康状态和备份，再按设备与阵列文档安排更换。不要把 mdadm --create 当成恢复已有阵列的通用命令。创建、持久组装及成员替换的完整条件见 mdadm(8) 和 Linux MD 文档。

PV、VG 与 LV#

1
/dev/sdb1（PV） ─┐                 ┌─ lvdata → XFS → /data
2
                ├─ vgdata（VG） ──┤
3
/dev/sdc1（PV） ─┘                 └─ lvlogs → ext4 → /srv/logs

VG 中未分配的空间和文件系统中的可用空间不是同一个量。vgs 的 VFree 表示还能分配给 LV 的空间，df 的 Avail 表示文件系统内还能使用的空间。

查看容量落在哪一层#

1
sudo pvs -o pv_name,vg_name,pv_size,pv_free
2
sudo vgs -o vg_name,vg_size,vg_free
3
sudo lvs -o lv_name,vg_name,lv_size,segtype,devices
4
findmnt -T /data

segtype 有助于识别线性卷、条带卷或精简卷等类型。下面的扩容流程针对普通厚置备 LV；thin pool 还需要单独观察数据区和元数据区，不能仅看 VFree。

扩容：先准备可分配空间#

有三种常见情况，应按实际结构选择，不要依次执行所有分支。

例如，确认 /dev/sdc 是可清空的独立新盘，且未挂载、未被 LVM/RAID/交换空间使用后，可以将整盘加入现有卷组。pvcreate 会写入 LVM 元数据，不能用于已有数据的设备：

1
sudo pvcreate /dev/sdc
2
sudo vgextend vgdata /dev/sdc
3
sudo pvs
4
sudo vgs

这里采用整盘 PV，不要再对这块盘创建分区。示例中的设备身份确认方法与新磁盘初始化示例相同。

如果平台扩大的是已有磁盘，应先用 lsblk 确认系统看到了新容量。PV 若在 /dev/sdb1 上，还需按实际布局扩大分区并让内核识别新边界，最后才运行 sudo pvresize /dev/sdb1；PV 若直接在整盘上，则对整盘执行 pvresize。扩大分区时必须保持原起始位置，不能通过重建文件系统“应用”新增空间。具体边界条件见 pvresize(8)。

扩容：扩大 LV 和文件系统#

假设 /dev/vgdata/lvdata 是普通 LV，已挂载到 /data，VG 至少还有 20 GiB 空闲空间。先确认设备与文件系统类型：

1
findmnt -T /data -o SOURCE,TARGET,FSTYPE,OPTIONS
2
sudo lvs /dev/vgdata/lvdata
3
sudo vgs vgdata

然后扩大 LV：

1
sudo lvextend -L +20G /dev/vgdata/lvdata

+20G 表示增加 20 GiB；没有 + 时表示目标总大小。LV 扩大后，文件系统还需要使用新增空间。以下两种命令按实际文件系统二选一。

1
sudo xfs_growfs /data

1
sudo resize2fs /dev/vgdata/lvdata

1
sudo lvs /dev/vgdata/lvdata
2
lsblk -f
3
findmnt -T /data
4
df -hT /data

缩容与快照的边界#

扩容和缩容不能简单反向操作。ext4 缩容需要卸载文件系统，按“备份 → 卸载 → 检查 → 缩文件系统 → 缩 LV → 挂载验证”的顺序处理。先缩 LV 可能截断文件系统仍在使用的区域。

XFS 的缩容能力应以发行版和工具版本正式支持的功能为准；在 RHEL 9 等常见部署中，应按不支持缩容规划，需要更小容量时采用迁移到新文件系统的方式，不把实验性能力作为通用操作方案。

LVM 快照保存某个时间点的卷视图，可辅助备份或短期回退，但它通常仍与原卷共享底层存储，不能替代独立备份。传统快照的写时复制空间耗尽会使快照失效；精简快照还受 thin pool 数据及元数据容量限制。数据库等应用也需要相应的一致性措施，不能把块层快照自动视为应用一致的备份。

深入操作可参考 LVM 管理文档。

ext4 与 XFS#

两者都支持日志功能，但日志主要帮助文件系统在异常后恢复一致性，不能保证应用尚未持久化的数据不丢失。文件系统也不存在脱离工作负载的绝对性能排名，选型还要考虑发行版支持、备份工具和恢复需求。

格式化会创建新的文件系统

对已有数据的设备执行 mkfs 可能破坏原有文件系统。挂载失败、空间未增加或设备显示异常时，都不应把重新格式化当作修复步骤。

FAT32、exFAT 与 NTFS：跨系统交换数据#

Linux 数据卷常用 ext4 或 XFS，但 U 盘、移动硬盘、Windows 分区和 EFI 系统分区还经常使用 FAT32、exFAT 或 NTFS。选择时除了容量，还要确认目标系统和设备的读写支持。

FAT32 的单文件限制与整个卷的容量是两回事：即使还有大量空闲空间，也无法保存一个 5 GiB 的文件。exFAT 解决了这类大文件交换需求，但不能因此认为所有只支持 FAT32 的设备都能识别 exFAT。FAT 的格式和 Linux 挂载行为可参考 Linux VFAT 文档，exFAT 的能力定义见 Microsoft exFAT 规范。

FAT32 和 exFAT 不像 ext4 那样持久保存每个文件的 Unix 属主与权限，Linux 通常通过 uid、gid、umask 等挂载选项呈现访问权限。需要 Unix 权限、符号链接等语义的服务数据目录，不宜仅为跨系统兼容而改用这两种格式。

使用 NTFS 时先确认发行版安装和启用了哪一种驱动；内核 ntfs3 与 ntfs-3g 的选项和支持能力不能混用。Windows 休眠或快速启动留下的卷状态可能使读写挂载被拒绝，应回到 Windows 完成正常关闭和必要检查，不用强制挂载绕过保护。内核驱动能力见 NTFS3 文档。

对已有设备，先用 lsblk -f 或 blkid 识别实际类型。缺少驱动或工具时按发行版安装相应支持，不要为解决“无法挂载”直接格式化；可移动存储写入结束后应正常卸载再拔出。

Btrfs 与其他常见挂载类型#

Btrfs 是 Linux 上另一种本地文件系统，支持写时复制、数据与元数据校验、子卷和快照。它适合需要这些能力且发行版与维护工具支持的场景；快照与原数据共享存储，不等于独立备份。子卷、共享数据和元数据分配还会影响容量统计，不能只按普通分区大小理解，可结合 btrfs filesystem usage <挂载点> 查看。具体选择与维护边界见 Btrfs 官方文档。

findmnt 还可能显示 tmpfs、nfs 或 cifs。这些应与本地磁盘文件系统区分：tmpfs 使用虚拟内存，可能使用交换空间，卸载或重启后数据不保留；NFS 和 SMB/CIFS 则通过网络访问远端存储。它们不是新建本地数据盘时与 ext4、FAT32 等直接互换的格式选项。

实际选择可以从用途出发：Linux 服务数据先考虑发行版支持的 ext4/XFS；需要子卷和快照等能力时评估 Btrfs；大文件跨系统交换常考虑 exFAT；兼容旧设备时核实 FAT32；已有 Windows 数据卷通常保留 NTFS 并确认驱动支持。

inode、目录项与文件内容#

以 ext4、XFS 等 Linux 文件系统为例，inode 保存文件类型、权限、属主、时间戳以及数据位置等元数据；目录项建立“名称 → inode”的关系。文件名属于目录内容，不是 inode 内部的文件名字段。不同文件系统的磁盘格式不同，不能把这套布局直接套到 FAT32 等格式上。

1
/data/report.csv ──目录项──► inode ──► 文件数据
2
/data/report.bak ──目录项──► 同一个 inode（硬链接）

删除一个名称不一定立即释放数据：还要看是否存在其他硬链接，以及是否有进程仍然打开这个文件。最后一个名称被删除但文件仍被进程打开时，空间通常要等最后一个引用关闭后才释放。

分别检查容量和 inode#

1
df -hT /data
2
df -i /data

df -hT 查看文件系统类型、容量及使用量，df -i 查看 inode 使用情况。大量小文件可能让 ext4 的 inode 先于数据空间耗尽；XFS 虽然动态分配 inode，也仍可能受剩余空间及元数据分配限制。

inode 耗尽时，定位文件数量异常的目录往往比只寻找大文件更有效。配额也可能限制特定用户或项目，即使整个文件系统还有空闲空间，也不代表所有写入都能继续。

挂载点与当前状态#

挂载把文件系统接到一个目录上。例如把 /dev/sdb1 挂载到 /data 后，访问 /data 就是在访问该文件系统。

1
sudo mkdir -p /data
2
sudo mount /dev/sdb1 /data
3
findmnt --mountpoint /data

挂载会遮住目录中原有内容，不会自动搬迁或合并这些文件。因此应先检查挂载点是否已被使用、目录中是否有数据。

findmnt -T /data 查找承载该路径的文件系统，即使 /data 并非独立挂载点，也可能返回根文件系统；findmnt --mountpoint /data 则用于核实 /data 本身是否已挂载。这一区别在排查“数据写到系统盘”时尤其重要。

UUID 与 /etc/fstab#

手工 mount 不会自动生成开机挂载配置。/etc/fstab 描述持久挂载关系，通常使用文件系统 UUID，避免依赖可能变化的设备枚举名称。

1
sudo blkid /dev/sdb1

例如，XFS 的配置行可以是：

1
UUID=11111111-2222-4333-8444-555555555555 /data xfs defaults 0 0

非根 ext4 数据卷通常使用末字段 2，根文件系统常为 1，还需结合发行版启动机制。磁盘克隆可能复制文件系统 UUID，因此 UUID 也需要避免重复。

nofail 适用于允许缺盘时继续启动的数据盘，不应为消除错误而无条件添加。若业务必须依赖 /data，还应确保服务在挂载失败时不会继续向根文件系统中的同名目录写入；systemd 服务可通过 RequiresMountsFor=/data 声明挂载依赖。

检查配置与实际挂载#

编辑前备份 fstab，编辑后先检查其可解析性和可用性：

1
sudo findmnt --verify --verbose

在 systemd 系统上，修改后还应让管理器重新加载配置：

1
sudo systemctl daemon-reload

对尚未挂载的新数据卷，可以执行 sudo mount /data，让 mount 从 fstab 读取来源、类型和选项，再用 findmnt --mountpoint /data 确认结果。

配置检查不等于实际挂载成功

findmnt --verify 不会真正挂载文件系统；mount -a 则会尝试挂载符合条件的 fstab 条目，并通常跳过已经挂载的文件系统。因此，mount -a 没有报错不能证明已有挂载的选项已经更新，也不能保证下次启动的所有依赖都满足。

对已使用的文件系统，应在合适的维护条件下验证重新挂载或卸载后挂载，不要为了测试配置直接中断业务。配置字段与行为见 fstab(5)、mount(8) 和 findmnt(8)。

卸载与占用检查#

1
sudo umount /data

出现 target is busy 时，先退出位于该挂载点内的工作目录，再检查进程和子挂载：

1
findmnt -R /data
2
sudo fuser -vm /data

让相关应用关闭文件或正常停止后，再重新卸载。umount -l 的延迟卸载不会立刻结束所有引用，不能把它作为后续格式化或修复已具备安全条件的证明。

1. 确认设备身份与挂载点#

1
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
2
sudo fdisk -l /dev/sdb
3
sudo wipefs --no-act /dev/sdb
4
sudo pvs
5
cat /proc/mdstat
6
swapon --show
7
findmnt --mountpoint /data

结合序列号、容量、平台分配记录或物理槽位确认目标。若已有分区，还需逐个检查其文件系统签名和用途；设备没有挂载也可能正在被 LVM、RAID、交换空间或其他程序使用。

findmnt --mountpoint /data 没有结果仅表示它不是当前挂载点。若目录已经存在，还要检查是否为空；若是符号链接或已有业务数据，先解决路径和迁移问题再继续。

下面的操作会改写目标设备

mklabel 会写入新的分区表，mkfs.xfs 会创建文件系统。只有设备身份、已有用途和数据保留要求都已确认后，才继续执行。发现旧签名或命令拒绝操作时先调查，不添加强制选项绕过保护。

2. 创建分区并等待系统识别#

1
sudo parted --script /dev/sdb mklabel gpt
2
sudo parted --script --align optimal /dev/sdb mkpart data xfs 1MiB 100%
3
sudo partprobe /dev/sdb
4
sudo udevadm settle
5
lsblk -o NAME,SIZE,TYPE,FSTYPE /dev/sdb

这里的 data 是 GPT 分区名称，xfs 是分区创建时的文件系统类型提示，文件系统尚未创建。确认 /dev/sdb1 已出现且大小符合预期；内核若无法重新读取分区表，应停止并检查占用情况。

3. 创建文件系统并临时挂载#

1
sudo mkfs.xfs /dev/sdb1
2
sudo mkdir -p /data
3
sudo mount /dev/sdb1 /data
4
findmnt --mountpoint /data -o SOURCE,TARGET,FSTYPE,OPTIONS
5
df -hT /data

预期来源为新分区，类型为 xfs，目标为 /data。新文件系统顶层目录通常由 root 拥有，后续应按应用用户分配目录和权限，不能用放开所有权限代替权限规划。

4. 保存配置并验证通过 fstab 挂载#

读取 UUID，并备份、编辑配置：

1
sudo blkid /dev/sdb1
2
sudo cp --backup=numbered /etc/fstab /etc/fstab.before-data
3
sudoedit /etc/fstab

加入一行，将占位内容替换为实际 UUID：

1
UUID=<实际文件系统UUID> /data xfs defaults 0 0

检查配置；以下按 systemd 系统示范：

1
sudo findmnt --verify --verbose
2
sudo systemctl daemon-reload

本例是尚未交给业务使用的新文件系统，可以退出该目录后卸载，再只指定挂载点进行挂载，以确认 fstab 条目被实际使用：

1
cd /
2
sudo umount /data
3
sudo mount /data
4
findmnt --mountpoint /data -o SOURCE,TARGET,FSTYPE,OPTIONS
5
df -hT /data

每一步失败都应先处理原因，不继续执行后续步骤。对照来源、类型、挂载点和容量确认结果后，再交给应用使用；不需要通过立即重启来试错。

空间不足：容量、inode 与配额#

假设异常路径位于 /data：

1
findmnt -T /data
2
df -hT /data
3
df -i /data
4
sudo du -xhd1 /data

du -x 限制在同一个文件系统内统计，避免把嵌套挂载也计算进来；-d1 先看一层目录，找到占用大的目录后再向下缩小范围。它需要遍历目录，大目录树上可能有明显 I/O 开销。

• 容量满：检查日志增长、临时文件、保留策略与业务数据，明确数据用途后再清理或扩容。
• inode 满：关注缓存、会话、队列等大量小文件目录；GNU du --inodes -x -d1 /data 可辅助查找。
• 总空间充足但特定用户写入失败：检查用户、组或项目配额；工具取决于文件系统与配额配置。

No space left on device 不只表示物理磁盘字节用完；Disk quota exceeded 则通常应优先检查配额。容器中还可能受自己的可写层、挂载命名空间或平台限制影响。

df 与 du 为什么不同#

df 统计文件系统分配情况，du 遍历可见目录并统计文件占用，两者口径不同。先确认统计的是同一个文件系统，并考虑权限不足、文件系统元数据和保留空间。

1
sudo lsof +L1

结合设备、路径、进程和文件大小判断是否与目标文件系统有关。若日志被删除但服务仍保持文件描述符，应按服务支持的方式重新打开日志，或安排正常重启；再比较 df 的变化。再次删除路径并不能释放那个已无名称的文件。

还有一种情况是：应用先向 /data 写入数据，随后在该目录挂载了另一文件系统。旧数据被遮住，但仍占用原文件系统的空间。检查这些数据需要合适的维护或独立查看方式，不应直接卸载正在使用的业务文件系统。

挂载失败或挂载点忙#

1
lsblk -f
2
sudo blkid /dev/sdb1
3
sudo findmnt --verify --verbose
4
sudo journalctl -k -b -n 100 --no-pager

按错误信息缩小范围：

1. 设备或 UUID 不存在：检查设备是否识别、阵列是否组装、LV 是否激活，以及配置是否引用了旧 UUID。
2. 类型、选项或超级块相关错误：核对实际文件系统类型、内核支持与挂载参数；通用报错不能单独证明文件系统损坏。
3. 目标目录不合适：检查路径、权限、现有挂载和子挂载。
4. 出现 timeout、reset 或 I/O error：继续检查控制器、链路、磁盘和阵列，不要只反复尝试挂载。

没有 systemd 日志的环境可查看 sudo dmesg。挂载点忙时结合 findmnt -R /data 和 fuser -vm /data 定位占用；不要直接强制终止未知业务进程。

只读、文件系统错误与修复边界#

1
findmnt -T /data -o SOURCE,TARGET,FSTYPE,OPTIONS
2
sudo journalctl -k -b -n 200 --no-pager

只读可能来自显式 ro 配置，也可能是文件系统错误后的保护行为。不同文件系统的反应不一样：ext4 可以按错误策略重新挂载为只读，XFS 遇到严重错误可能进入 shutdown 状态，此时即使挂载选项仍显示 rw，读写也可能返回错误。

先确认底层存储健康，再制定备份、维护和修复方案。不要把 mount -o remount,rw 当成通用修复，也不要直接对仍在使用的文件系统运行离线修复工具。

即便是不修改模式，也需要考虑故障盘的读取压力。介质持续报错时应优先考虑数据保护，而不是反复扫描。XFS 的 xfs_repair -L 会清除日志，可能丢失元数据更新，不应作为默认选项。

维护条件和恢复限制见 e2fsck(8) 与 xfs_repair(8)。

RAID 降级与 LVM 容量异常#

RAID 降级时先使用 cat /proc/mdstat 和 mdadm --detail 确认成员及重建状态；硬件 RAID 则使用控制器工具。重建会增加剩余成员负载，阵列仍可读写不代表冗余已经恢复。

LVM 容量异常可以逐层比较：

1
lsblk：磁盘、分区是否已变大？
2
   ↓
3
pvs：PV 是否已经识别新增空间？
4
   ↓
5
vgs：VG 是否有可分配的空闲空间？
6
   ↓
7
lvs：目标 LV 是否已扩大？
8
   ↓
9
findmnt + df：是否查看了正确的文件系统，它是否已扩容？

如果 LV 已经变大而 df 没变化，通常应检查文件系统扩容步骤；如果 PV 缺失，先检查设备、阵列与连接状态，不能对原设备重新执行 pvcreate。

I/O 性能：把指标与负载一起看#

存储性能至少包含三个维度：

同样是 10,000 IOPS，4 KiB 请求对应的吞吐量约为 39 MiB/s，1 MiB 请求则约为 9.8 GiB/s。因此不能脱离请求大小比较 IOPS，也不能拿顺序大块吞吐量推断数据库随机访问表现。

安装 sysstat 后，可持续观察设备与进程：

1
iostat -xz -y 1
2
pidstat -d 1

两条命令可在不同终端运行。iostat 的 -y 跳过启动以来的首份累计报告，便于观察当前区间。常用字段如下，具体名称可能随版本变化：

%iowait 是 CPU 时间统计中的一个类别，不是磁盘忙碌率，也不能直接定位哪块盘出现瓶颈。应把设备延迟、队列、吞吐、应用响应时间与正常基线一起比较，并检查是否存在阵列重建、备份扫描、温度节流、链路重置等变化。

如果需要继续确认设备健康，可按设备类型使用 smartctl -a <设备> 或 nvme smart-log <控制器设备>；硬件 RAID 后的磁盘可能需要控制器专用透传参数。健康状态正常也不能排除链路或性能问题。

指标定义见 iostat(1)。内核请求队列的实现细节可继续阅读 blk-mq。