Linux 文件系统与存储面试题
9 道题- 分类
- Linux
- 题目数
- 9 道
已阅读 0 / 9 题
1 ext4、xfs、btrfs 三种主流文件系统的特点与适用场景分别是什么？
答案：
| 维度 | ext4 | xfs | btrfs |
|---|---|---|---|
| 最大单文件 | 16TiB（48-bit 块号 × 4KB） | 8EB | 16EB |
| 最大文件系统 | 1EB | 8EB | 16EB |
| 日志 | 有序/数据日志 | 有序日志 | COW + 写时复制 |
| 快照 | 不支持 | xfs_db + xfs_freeze 间接 | 原生支持（快照秒级） |
| 在线扩容 | 有限（resize2fs） | 强（xfs_growfs） | 支持 |
| 压缩 | 不支持 | 不支持 | 原生 zlib/lz4/zstd |
| CoW 行为 | 无 | 无 | 有（影响数据库） |
| 适合场景 | 通用、稳定 | 大文件、大容量、高并发 | 快照、备份、容器镜像 |
关键差异：
- ext4：成熟稳定，extents + 多块分配 + 延迟分配；CentOS 7 / Ubuntu 18.04 默认。
- xfs：基于 B+ 树管理 inode 与 extent，allocation group 并行分配；RHEL/CentOS 8+ 默认，大文件与高并发 IO 性能优异。
- btrfs：写时复制（Copy-on-Write）、子卷、快照、校验和、压缩、RAID 内置；但 CoW 对 MySQL/PostgreSQL 极不友好（双写放大、随机写退化），SUSE 14 早期使用，主流数据库场景仍需关闭 CoW：
chattr +C /data。
# 查看文件系统类型
lsblk -f
df -T
2 inode 是什么？硬链接与软链接在 inode 层有什么区别？
答案：
inode（index node）是文件系统中描述文件元数据的数据结构，包含权限、所有者、时间戳、块位图、文件大小、数据块指针等（ext4 约 256 字节），文件名仅是**目录项（dentry）**到 inode 的映射。
目录 → dentry → inode → data blocks 关系：同一 inode 可对应多个目录项（硬链接），删除文件实际是删除 dentry，待 inode 引用计数 i_nlink 归零才真正释放数据块。
硬链接 vs 软链接：
| 维度 | 硬链接 | 软链接（符号链接） |
|---|---|---|
| inode 关系 | 与源文件共用同一 inode | 独立 inode，内容为目标路径字符串 |
| 跨文件系统 | 不支持（inode 号仅在 FS 内唯一） | 支持 |
| 删除源文件 | 不影响硬链接（数据仍在） | 软链接失效（悬挂链接） |
| 目录限制 | 目录硬链接会形成环，禁止（. .. 除外） | 支持目录 |
| 链接数 | i_nlink++ | dentry 指向新 inode |
常见问题：
No space left on device但df -h显示有空间：实际是 inode 耗尽（大量小文件导致）。
# 查看 inode 使用率
df -i
3 RAID 各级别的特点是什么？生产环境如何选型？
答案：
RAID（Redundant Array of Independent Disks）通过数据条带化（Striping）、镜像（Mirroring）、校验（Parity） 在多盘上提供性能、可靠性或容量扩展。
| 级别 | 冗余 | 空间利用率 | 读性能 | 写性能 | 容错 | 适用场景 |
|---|---|---|---|---|---|---|
| RAID 0 | 无 | 100% | 高 | 高 | 0 | 临时数据、高性能计算 |
| RAID 1 | 镜像 | 50% | 高 | 中 | 1 盘 | 系统盘、小容量高可靠 |
| RAID 5 | 单校验 | (n-1)/n | 高 | 中 | 1 盘 | 读多写少、归档 |
| RAID 6 | 双校验 | (n-2)/n | 高 | 中低 | 2 盘 | 大容量、写密集 |
| RAID 10 | 镜像+条带 | 50% | 高 | 高 | 每组 1 盘 | 数据库首选 |
| RAID 50/60 | 校验+条带 | 高/中 | 高 | 中 | 多盘 | 大容量、高吞吐 |
关键概念：
- 写惩罚（Write Penalty）：RAID 5 一次写 = 2 读 + 2 写（读旧数据、旧校验、写入新数据、新校验）；RAID 6 一次写 = 3 读 + 3 写。电池保护（BBU / Supercap） 至关重要。
- 软件 vs 硬件 RAID：硬件 RAID 卡有 BBU 缓存、专用 IO 处理器；现代 CPU 强劲，Linux
mdadm软件 RAID 性能已接近硬件且更灵活。 - 云盘 RAID：云厂商块存储（EBS / 云盘）通常底层已多副本，再做 RAID 0 仅是聚合带宽，反而增加风险。
生产建议： 数据库 → RAID 10；对象存储 / 视频 → RAID 6/60；NVMe SSD 阵列 → 考虑 RAID 0 + 分布式副本。
4 LVM 与 device-mapper 的关系是什么？LVM 的三层结构如何理解？
答案：
LVM（Logical Volume Manager）是用户空间逻辑卷管理工具集，底层依赖内核 device-mapper（dm）模块提供的块设备重映射能力。dm 内核驱动将一个或多个物理设备映射为虚拟块设备（/dev/dm-N），并维护映射表（target table）描述 IO 路由。
LVM 三层结构：
PV (Physical Volume) → 物理卷（整块磁盘或分区，初始化时写入 LVM 元数据）
↓
VG (Volume Group) → 卷组（多个 PV 组成的存储池）
↓
LV (Logical Volume) → 逻辑卷（VG 上划出的可动态伸缩块设备）
关键机制：
- PE（Physical Extent）：默认 4MB，PV 切分为 PE；LE（Logical Extent） 与 PE 一一映射。
- 线性卷（Linear）：LE 顺序映射到不同 PV 的 PE。
- 条带卷（Striped）：LE 跨 PV 轮询分布，性能优于线性卷。
- 快照（Snapshot）：COW 机制，对原 LV 数据变更时先复制到快照卷；写密集场景快照性能差，生产建议用 thin snapshot（thinpool）。
应用场景：
- 在线扩容文件系统（
lvextend+resize2fs/xfs_growfs）。 - 多盘聚合为大容量卷组。
- 快照备份（MySQL LVM 快照 + xtrabackup）。
- Thin Provisioning：按需分配空间，提高存储利用率。
# 完整流程
pvcreate /dev/sdb
vgcreate vg_data /dev/sdb
lvcreate -L 100G -n lv_mysql vg_data
mkfs.xfs /dev/vg_data/lv_mysql
mount /dev/vg_data/lv_mysql /data
5 Linux 文件权限模型详解：SUID/SGID/Sticky Bit 各自的用途是什么？
答案：
Linux 文件权限是 SRE 必知基础，权限位 12 位（4 类 × 3 比特），表示为 rwxr-xr-x：
| 位 | 八进制 | 含义 |
|---|---|---|
r | 4 | 读 |
w | 2 | 写 |
x | 1 | 执行 |
s（user x 位） | 4000 | SUID（set user id） |
s（group x 位） | 2000 | SGID（set group id） |
t（other x 位） | 1000 | Sticky Bit |
SUID（Set User ID）：
- 文件执行时，进程有效 UID = 文件所有者 UID
- 经典例子：
/usr/bin/passwd属主 root → 用户执行 passwd 时，有效 UID=0，可写/etc/shadow - 安全风险：SUID root 文件可被攻击者利用提权，生产需审计：
find / -perm -4000 -type f 2>/dev/null - 限制：
/etc/sudoers限制 SUID 程序行为
SGID（Set Group ID）：
对文件：执行时进程有效 GID = 文件属组 GID
对目录：目录内新建文件/子目录自动继承父目录属组（团队协作目录必备）
mkdir /project chgrp devteam /project chmod 2775 /project # SGID + 775 # /project 内新建文件自动属 devteam 组
**Sticky Bit（粘滞位）：**
- 仅对**目录**有效：目录内文件**只有所有者（和 root）能删/重命名**
- 经典例子：`/tmp`（任何用户可写，但不能删别人的文件）
```bash
ls -ld /tmp
# drwxrwxrwt 10 root root 4096 /tmp
# ^ t 即 sticky bit
chmod 1777 /shared/upload # 用户上传目录必备
权限计算示例：
-rwsr-xr-x 1 root root 68208 May 28 /usr/bin/passwd
├ 类型 -（普通文件）
├ 属主 rwx → 7
├ 属组 r-x → 5
├ 其他 r-x → 5
└ SUID 位 → 4
chmod 4755 /usr/bin/passwd
ACL（Access Control List）： 当基础 rwx 不够用时（如"用户 alice 对 file 有 rw-“但 alice 不在属组里）：
# 安装 acl 工具（部分镜像默认未装）
apt install acl
# 设置 ACL
setfacl -m u:alice:rw- /data/file
setfacl -m g:devteam:rwx /data/project
# 查看 ACL
getfacl /data/file
# 递归
setfacl -R -m u:alice:rwx /data/project
# 默认 ACL（目录内新建文件继承）
setfacl -d -m u:alice:rwx /data/project
umask 决定默认权限：
- 用户默认
umask=0022→ 新建文件 644，目录 755 - 服务账号常设
umask=0077→ 私有 600/700
6 dd / fio / ioping 三大磁盘 IO 基准测试工具有什么区别？如何选用？
答案：
磁盘性能测试是 SRE 必备技能，三个工具定位不同：
dd（最简单，单线程顺序 IO）：
# 顺序写测试（不靠谱但最简单）
dd if=/dev/zero of=/data/test bs=1M count=1024 oflag=direct
# 1073741824 bytes (1.1 GB) copied, 4.5 s, 238 MB/s
# 顺序读测试
dd if=/data/test of=/dev/null bs=1M iflag=direct
# 注意：写一次再读，避开 Page Cache 影响
dd 局限：单线程、不测 IOPS、不能测随机读写、不能混合比例。
fio（专业级，多模式可配置）：
# 安装
apt install fio
# 或 yum install fio
# 顺序读 4K 块
fio --name=seq-read --filename=/data/test --rw=read --bs=4k \
--size=1G --numjobs=1 --runtime=30 --time_based --direct=1 \
--ioengine=libaio --iodepth=32
# 关键指标：BW (bandwidth)、IOPS、lat (latency)
# 随机写 4K（测 IOPS，最关键指标）
fio --name=rand-write --filename=/data/test --rw=randwrite --bs=4k \
--size=1G --numjobs=4 --runtime=60 --time_based --direct=1 \
--ioengine=libaio --iodepth=64
# 混合读写 70/30（数据库场景）
fio --name=mix --filename=/data/test --rw=randrw --rwmixread=70 \
--bs=4k --size=1G --numjobs=4 --runtime=60 --time_based \
--direct=1 --ioengine=libaio --iodepth=32
# 关键参数：
# --bs=4k 块大小（数据库 4K-8K，大文件 1M）
# --rw= read/write/randread/randwrite/randrw
# --iodepth= 队列深度（NVMe 高，HDD 低）
# --numjobs= 并发线程
# --runtime= 测试时长
# --direct=1 绕过 Page Cache（必加）
# --ioengine= libaio (Linux AIO) / io_uring / psync
ioping（快速测延迟）：
# 测磁盘响应时间
ioping -c 100 /data/
# 4 KiB <<< /data/ (xfs /dev/sda1): request=1 time=212.3 us (warmup)
# 4 KiB <<< /data/ (xfs /dev/sda1): request=2 time=189.7 us
# ...
# --- /data/ (xfs /dev/sda1) ioping statistics ---
# 99 requests completed in 31.2 ms, 3.18 MiB read
# min/avg/max/mdev = 178.4 us / 315.2 us / 1.2 ms / 89.4 us
# 注：ioping 默认会先发 1 个 warmup 请求，故 -c 100 实际统计 99 个；如需 100 个测试请求用 -c 101 或 -W 0 关闭 warmup
# 测顺序读写速率
ioping -R -s 1G -c 10 /data/
# 1 GiB <<< /data/ ...
# --- ioping statistics ---
# 10 requests completed in 2.3 s, 10 GiB read
# min/avg/max/mdev = 215.6 MiB/s / 234.1 MiB/s / 245.3 MiB/s / ...
工具选用：
| 工具 | 适合场景 | 关键指标 |
|---|---|---|
| dd | 快速验证、脚本嵌入式 | 顺序吞吐（MB/s） |
| fio | 生产级基准、容量规划 | IOPS / BW / latency / 99p |
| ioping | 延迟诊断、快速 smoke test | 响应时间（μs） |
生产环境评估建议：
- 新购存储：先
fio全模式（顺序 + 随机 + 混合 + 不同 bs + 不同 iodepth） - 上线后基线：用
fio跑 30 分钟记录 IOPS/latency - 日常巡检：
ioping -c 100看延迟（数据库 < 1ms 正常） - 性能下降诊断：
fio+iostat -dx 1+perf三件套
7 iostat 字段详解：%util / await / svctm / aqu-sz 各代表什么？
答案：
iostat -dx 1 是磁盘 IO 监控的核心命令，输出字段含义经常被误读：
典型输出：
Device r/s w/s rkB/s wkB/s await r_await w_await svctm %util
sda 12.3 456.7 156.8 18264.5 4.32 0.56 4.45 0.85 38.2
sdb 234.5 1024.5 5632.0 40960.0 18.7 5.2 19.5 1.2 95.8
关键字段解读：
| 字段 | 含义 | 常见误解 |
|---|---|---|
| r/s, w/s | 每秒读/写次数 | 单位是 IOPS |
| rkB/s, wkB/s | 每秒读/写 KB 数 | 单位 KB/s |
| await | 每个 IO 的平均等待时间（ms） | 含队列等待 + 服务时间 |
| r_await / w_await | 分别读/写等待时间 | 用于区分读慢还是写慢 |
| svctm | 设备服务时间（ms） | 已废弃，数据不可靠 |
| %util | 设备繁忙时间百分比 | 不等于 IO 饱和度！ |
| aqu-sz | 平均队列长度 | 真正的饱和度指标 |
| rareq-sz / wareq-sz | 平均读/写请求大小（KB） | 用于判断 IO 模式 |
%util 误解：
- ❌ “%util 100% = 磁盘满载”
- ✅ “%util 100% = 磁盘至少有一个 IO 在处理（无法并行处理多 IO 时才饱和）”
- 真相：%util 100% 只能说明磁盘不空闲，不代表 IO 被打爆。现代磁盘支持 NCQ/TCQ，可并行处理多 IO，%util 100% 但 aqu-sz 很低说明还有余量
- 真正饱和指标：aqu-sz / queue_depth（如 NVMe 队列深度 32，aqu-sz=20 表示基本饱和）
await 解读：
- 机械盘（HDD）：
- < 5ms 正常
- 5-10ms 偏高
20ms IO 性能严重问题
- SSD/NVMe：
- < 0.5ms 优秀
- 0.5-2ms 正常
5ms 异常
- await ≈ r_await/w_await 加权平均，用于分离诊断
实战排障：
# 1. 高 %util 但低 IOPS → 单 IO 慢（latency-bound）
iostat -dx 1
# Device r/s w/s await %util
# sda 10 20 45.2 95.0 # 20 IOPS 但 await 45ms → 慢盘
# 2. 高 aqu-sz + 高 await → 队列堆积
# aqu-sz=128 await=20ms → 队列深 128，IO 卡顿严重
# 3. NVMe vs SATA SSD 性能差
# 即使 %util 都不高，NVMe 4K 随机 IOPS 50万 vs SATA 8万
# 4. 高 r_await 单独高 → 读路径问题（缓存未命中、慢盘）
# 高 w_await 单独高 → 写路径问题（fsync 慢、写放大）
# 综合命令
iostat -dx -p ALL 1 # 看所有设备 + 分区
iotop -o # 看进程级 IO
pidstat -d 1 # 看进程 IO 统计
生产基线建立：
- 在新存储上线时，跑
fio同时记录iostat输出，建立业务时段基线（如IOPS 5万、await 0.3ms、aqu-sz 2） - 监控告警：
aqu-sz > 30或await > 5ms触发
8 磁盘调度算法（IO Scheduler）有哪些？各适合什么场景？
答案：
磁盘调度算法决定内核向设备发 IO 请求的顺序，影响吞吐和延迟。Linux 内核提供多种调度器：
历史与可用调度器：
| 调度器 | 引入 | 特点 | 适合 |
|---|---|---|---|
| noop | 2.6+ | 简单 FIFO，几乎无调度 | NVMe、SSD、虚拟化 guest（hypervisor 已调度） |
| deadline | 2.6+ | 防止 IO 饥饿，读/写分别 FIFO + 超时 | 数据库（MySQL/PostgreSQL）默认 |
| cfq | 2.6 - 4.20 | 完全公平队列，按进程分配 IO 带宽 | 桌面 / 旧系统（已废弃） |
| bfq | 4.12+ | 改进版 CFQ，按**预算（budget）**分配，低队列深度低延迟 | 桌面、嵌入式 |
| kyber | 4.12+ | 基于令牌桶，延迟可预测 | NVMe、低延迟需求 |
| mq-deadline | 5.0+ | 多队列版 deadline | NVMe + 数据库 |
deadline 核心机制：
- 维护 4 个队列：读 FIFO、读 LIFO、写 FIFO、写 LIFO
- 默认读 500ms、写 5s 超时，到期强制调度
- 读优先（避免读饥饿），合并相邻请求
- 适合读多写少、有事务延迟要求的数据库
kyber 核心机制：
- 维护令牌桶：
read_tokens、write_tokens - IO 请求消耗令牌，无令牌时限制
- 可调参数：
read_lat_nsec、write_lat_nsec（目标延迟） - 适合低延迟 SSD、KV 存储
配置方法：
# 查看当前调度器
cat /sys/block/sda/queue/scheduler
# [mq-deadline] kyber bfq none # [] 包裹的是当前
# 切换调度器
echo mq-deadline > /sys/block/sda/queue/scheduler
echo kyber > /sys/block/nvme0n1/queue/scheduler
# 调优 deadline 参数
echo 50 > /sys/block/sda/queue/iosched/read_expire # 读超时 50ms（默认 500ms）
echo 5000 > /sys/block/sda/queue/iosched/write_expire # 写超时 5s
# 调优 kyber 目标延迟
echo 100000 > /sys/block/nvme0n1/queue/iosched/read_lat_nsec # 100μs
echo 1000000 > /sys/block/nvme0n1/queue/iosched/write_lat_nsec # 1ms
# 队列深度（NVMe 调高，HDD 不变）
cat /sys/block/nvme0n1/queue/queue_depth # 默认 1023
# 关闭预读（数据库场景）
echo 0 > /sys/block/sda/queue/read_ahead_kb
生产选型建议：
| 场景 | 推荐调度器 | 原因 |
|---|---|---|
| NVMe SSD + 数据库 | none 或 kyber | NVMe 设备自身调度能力强 |
| SATA SSD + 数据库 | mq-deadline | 延迟可控 + 防饥饿 |
| NVMe + 通用 | none（noop） | 让 NVMe 自管理 |
| HDD + 数据库 | mq-deadline | 减少寻道，合并请求 |
| 虚拟化 guest | none | hypervisor 已调度 |
| 云盘（EBS/云盘） | none | 虚拟设备，无物理寻道 |
数据库场景特别说明：
- MySQL/PostgreSQL 建议关闭 IO 调度器影响（直传 NVMe）→ 使用
none - 不建议修改
nr_requests（请求队列长度）除非明确知道后果 - 多队列（multi-queue blk-mq）下，
none等同于noop
9 网络文件系统（NFS / iSCSI）的工作原理与挂载优化是什么？
答案：
NFS（Network File System）和 iSCSI 是企业存储的两大主流网络协议。
NFS 核心概念：
- 基于 RPC（v3 之前）/ 原生 TCP（v4.1+）
- 无状态 / 有状态：NFS v3 客户端可重发请求，v4 引入会话概念
- 文件锁：v4 集成 lock manager，v3 依赖 NLM（Network Lock Manager）
- 协议端口：NFS 2049/TCP、mountd 动态、statd 动态
NFS 挂载与参数：
# 安装工具
apt install nfs-common # 客户端
apt install nfs-kernel-server # 服务端
# 服务端导出
echo "/data 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)" \
>> /etc/exports
exportfs -a
systemctl restart nfs-server
# 客户端挂载
mount -t nfs 192.168.1.10:/data /mnt/nfs
# 或写入 /etc/fstab
192.168.1.10:/data /mnt/nfs nfs defaults,_netdev,noatime,nodiratime 0 0
# 关键挂载参数
# -o rsize=1048576,wsize=1048576 大块读写（默认 rsize=1MB 上限）
# -o hard/soft hard=IO 永久重试（推荐）,soft=超时返回错误
# -o timeo=600,retrans=3 重试 3 次每次 60s
# -o noatime,nodiratime 不更新访问时间（性能提升）
# -o async 服务端异步写（性能好但不安全）
# -o vers=4.2 强制 NFS v4.2
# -o sec=sys/krb5i/krb5p 认证方式：sys（弱）/krb5i（完整性）/krb5p（加密）
NFS 性能调优：
# 1. 客户端内核参数
sysctl -w sunrpc.tcp_slot_table_entries=128 # TCP 并发槽位
sysctl -w sunrpc.tcp_max_slot_table_entries=128
# 2. 调整 nfsd 线程数（服务端）
echo 64 > /proc/fs/nfsd/threads
# 3. 查看挂载性能
nfsstat -c # 客户端统计
nfsstat -s # 服务端统计
nfsiostat # 类似 iostat 的 NFS 版
# 4. 性能监控
mount -t nfs -o rsize=1M,wsize=1M server:/data /mnt/nfs
dd if=/mnt/nfs/test of=/dev/null bs=1M count=1024 iflag=direct
NFS 常见问题：
- stale file handle：服务端 export 路径变化或文件被删，客户端需
umount -f /mnt/nfs; mount ... - 卡死进程（不可中断 D 态）：NFS server 不可达 +
hard挂载，进程永久 hang - 解决方案：客户端使用
soft挂载 + 短超时（适合批处理）；或hard+intr（v4 已忽略） - 性能抖动：网络不稳导致 RPC 重传，生产用专用存储网络（如 25Gbps）
iSCSI 核心概念：
- 基于 SCSI 协议 over TCP/IP
- 块设备（不是文件系统），客户端拿到
/dev/sdb设备 - Initiator（客户端）→ Target（服务端）→ 后端存储
- 端口：3260/TCP
iSCSI 配置：
# 客户端（initiator）
apt install open-iscsi
iscsiadm -m discovery -t sendtargets -p 192.168.1.20
iscsiadm -m node -l # 登录 target
# /dev/sdb 出现，可直接 fdisk/mkfs/mount
# 服务端（target）
apt install targetcli-fb
targetcli
# /backstores/block create mydata /dev/sdb
# /iscsi create iqn.2024-01.com.example:storage
# /iscsi/iqn.../tpg1/luns create /backstores/block/mydata
# /iscsi/iqn.../tpg1/acls create iqn.2024-01.com.example:client
# /iscsi/iqn.../tpg1/portals create 0.0.0.0 3260
targetcli saveconfig
iSCSI vs NFS 对比：
| 维度 | NFS | iSCSI |
|---|---|---|
| 协议层 | 文件系统 | 块设备 |
| 客户端可见 | /mnt/nfs/file | /dev/sdb1 |
| 文件系统 | 客户端决定 | 客户端格式化 |
| 多客户端共享 | ✅（v4 文件锁） | ❌（需集群 FS 如 GFS、OCFS2） |
| 性能 | 中（TCP+RPC） | 高（裸块） |
| 数据库 | 适合 BI/分析 | 适合 Oracle/RDBMS |
| 容器存储 | 常用 | 块存储后端 |
| 典型延迟 | 1-5ms | 0.5-2ms |
生产建议：
- 多客户端共享用 NFS（v4.2 支持并行）
- 单客户端高性能（数据库）用 iSCSI 或 FC
- 容器持久化用 iSCSI / NVMe-oF 后端
- 网络必须独立（VLAN 25Gbps+，Jumbo Frame MTU 9000）