1. 项目概述：为什么“看懂硬盘”比“换块新盘”更重要
在某高校实验室维护一批老旧工作站时，我遇到过这样一件事：一台运行了六年的服务器突然频繁报I/O错误，系统日志里满屏都是ata4.00: failed command: READ FPDMA QUEUED。运维同事第一反应是“硬盘坏了”，立刻下单采购同型号新盘准备更换。结果新盘到货后一插上，系统照样卡死——最后发现根本不是硬盘物理损坏，而是主板SATA控制器固件存在已知缺陷，只在特定型号的SSD上触发异常中断。真正的问题藏在SMART数据里一行不起眼的Command Timeout计数暴增，而这块盘的型号、固件版本、通电时间、重分配扇区数全部正常。这件事让我彻底意识到：Linux下查看硬盘信息，从来不是为了凑齐几个参数截图交差，而是要建立一套完整的“硬盘健康认知框架”——型号决定兼容性边界，容量反映逻辑布局结构，健康状态才是真实服役能力的量化表达。这套框架不依赖GUI工具，不迷信厂商宣传，只靠终端里几条命令的组合逻辑和参数含义的深度理解。它适用于所有Linux发行版，从树莓派的轻量级系统到企业级存储节点；它不挑硬件，无论是NVMe SSD、SATA机械盘、USB移动硬盘，还是RAID阵列中的单块成员盘；它解决的是最底层的“信任问题”：你敢不敢把重要数据写进这块盘？你能不能预判它下周会不会突然掉线？你是否清楚当前IO瓶颈到底出在盘本身、接口协议，还是文件系统层？如果你还在用df -h看剩余空间就以为掌握了硬盘状况，或者靠lsblk列出设备名就认为完成了资产盘点，那这套攻略就是为你写的——它不教你怎么装软件，只告诉你每一条命令背后，硬盘固件、内核驱动、用户空间工具之间究竟发生了什么。
2. 硬盘信息分层解析：从物理识别到健康诊断的四层穿透法
Linux对硬盘的认知不是扁平的，而是严格遵循硬件抽象层级：物理层 → 接口层 → 设备层 → 逻辑层。每一层提供不同维度的信息，跳过任何一层都会导致误判。比如只看/dev/sda这个设备名，你完全不知道它背后是NVMe协议的PCIe SSD还是USB转接的旧机械盘；只查SMART健康值，却忽略固件版本号，可能错过已知的批量缺陷公告。下面这张表不是简单罗列命令，而是按认知层级拆解每个信息点的来源、意义和交叉验证逻辑：
| 层级 | 关键信息点 | 核心命令 | 为什么必须查这一项 | 实际误判案例 |
|---|---|---|---|---|
| 物理层 | 厂商、型号、序列号、固件版本 | `sudo hdparm -I /dev/sda | grep -E "(Model | Serial | Firmware)"` |
| 接口层 | 协议类型（SATA/NVMe/USB）、链路速率、传输模式 | `sudo smartctl -i /dev/sda | grep -E "(Device Model | Protocol | Transport)"+lspci -vv -s $(lspci | grep -i nvme | awk '{print $1}') | grep -A5 "LnkSta"` |
| 设备层 | 设备路径、主次设备号、分区布局、挂载点 | lsblk -f -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL,UUID | /dev/nvme0n1p1和/dev/sda1的IO调度器默认策略完全不同（mq-deadline vs kyber），影响数据库随机读写性能 | MySQL服务器IO延迟突增，查lsblk发现数据盘被误挂载为/dev/sdb（本应是/dev/nvme0n1），调度器未启用NVMe优化 |
| 逻辑层 | 文件系统类型、块大小、已用/可用空间、inode使用率 | `df -h -T -i | grep -E "(sda | nvme | vda)"` |
这种分层不是教科书式的理论划分，而是实操中必须遵循的排查顺序。我处理过的87%的硬盘相关故障，根源都在物理层或接口层被忽略——比如一块标称“1TB”的SSD，在lsblk里显示为931.5G，这是正常的十进制/二进制换算差异；但如果显示为465G，那大概率是BIOS里启用了Legacy Boot模式，将NVMe盘识别为IDE设备导致容量截断。再比如smartctl -a报告Reallocated_Sector_Ct为0，看似健康，但若同时发现UDMA_CRC_Error_Count持续增长，说明数据线接触不良或主板SATA口供电不稳，这才是真正的风险源。所以，真正的“全攻略”不是堆砌命令，而是建立这种穿透式思维：看到一个数值，立刻追问它在哪一层产生、受哪些硬件因素影响、与其他层数据是否自洽。
3. 核心命令深度实操：从入门到精准诊断的七步工作流
很多教程把smartctl、hdparm、lsblk当独立工具教，导致用户记不住何时该用哪个。实际上，它们构成了一条完整的诊断流水线。我给自己定了一套七步工作流，每次接手新机器或排查异常，都像手术刀一样逐层切开硬盘真相。下面以一块实测的西部数据SN750 1TB NVMe SSD为例，全程展示每一步的命令、输出关键字段解读、以及我为什么这样操作：
3.1 第一步：快速定位设备与基础属性（30秒建立坐标系）
# 不加sudo也能执行，获取设备树快照 lsblk -d -o NAME,MODEL,SERIAL,SIZE,ROTA,TYPE,FSTYPE,MOUNTPOINT输出关键行：
nvme0n1 WDS100T3X0C-00SJG0 21457A800001 953.9G 0 disk └─nvme0n1p1 953.9G 0 part ext4 /mnt/data为什么这步不可跳过？
ROTA=0确认是固态盘（机械盘为1），直接排除寻道时间相关的性能问题TYPE=disk而非rom或part，说明是裸设备而非分区，后续SMART检测需针对/dev/nvme0n1而非/dev/nvme0n1p1MODEL字段里的WDS100T3X0C-00SJG0是完整型号，去WD官网搜这个型号，能查到它的TRIM支持状态、功耗曲线、已知问题（如该型号在Linux 5.4内核下需加nvme_core.default_ps_max_latency_us=5500启动参数）
提示：
lsblk -d只显示磁盘设备，避免被子分区干扰；-o指定输出列，聚焦核心字段。新手常犯错误是直接lsblk然后在一堆nvme0n1p1、nvme0n1p2里找主设备，效率极低。
3.2 第二步：验证协议与物理连接质量（揪出隐藏瓶颈）
# 查NVMe盘详细信息（SATA盘用smartctl -i /dev/sda） sudo smartctl -i /dev/nvme0n1输出关键段：
Device Model: WDS100T3X0C-00SJG0 Serial Number: 21457A800001 Firmware Version: 101210WD PCI Vendor/Subsystem ID: 0x15b7 IEEE OUI Identifier: 0x001b44 Total NVM Capacity: 1,000,204,886,016 [1.00 TB] Unallocated NVM Capacity: 0 Controller ID: 1 Number of Namespaces: 1 Namespace 1 Size/Capacity: 1,000,204,886,016 [1.00 TB]重点看三个字段：
Firmware Version: 101210WD：去WD支持页搜索此固件，发现2021年发布的101210WD版本修复了“在高队列深度下偶发超时”问题。如果机器恰好运行在数据库高并发场景，这个信息就是性能优化的关键线索。PCI Vendor ID: 0x15b7：对应Western Digital，确认非白牌OEM盘（OEM盘常锁固件升级）。Number of Namespaces: 1：单命名空间，排除多NS配置导致的容量计算异常。
补充验证链路质量（仅NVMe）：
# 查PCIe链路状态，确认是否降速 sudo lspci -vv -s $(lspci | grep -i "non-volatile memory" | head -1 | awk '{print $1}') | grep -A5 "LnkSta"输出中LnkSta: Speed 8GT/s, Width x4表示PCIe 3.0 x4满速；若显示Speed 2.5GT/s, Width x1，则说明被降为PCIe 1.0 x1，带宽只剩1/16，必须检查主板M.2插槽规格或BIOS设置。
3.3 第三步：容量与分区校验（避开厂商营销陷阱）
# 获取精确物理容量（十进制GB） sudo hdparm -I /dev/nvme0n1 | grep "device size" # 获取逻辑块数与大小 sudo blockdev --getsz /dev/nvme0n1 # 返回总扇区数 sudo blockdev --getss /dev/nvme0n1 # 返回扇区大小（通常512或4096）计算验证：
blockdev --getsz返回1953525168（扇区数）blockdev --getss返回512（字节/扇区）- 物理容量 = 1953525168 × 512 = 1,000,204,886,016 字节 =1.00 TB（与SMART报告一致）
- 而厂商标称“1TB”按十进制算为1,000,000,000,000字节，差值204MB属于正常范围。
注意：某些山寨SSD会通过固件造假，让
blockdev --getsz返回虚假大值，但实际写入超过标称容量就会丢数据。此时需用badblocks -wsv /dev/nvme0n1进行全盘写入校验（耗时数小时，生产环境慎用）。
3.4 第四步：健康状态初筛（SMART核心指标解读）
# 获取完整SMART数据（NVMe盘必须用smartctl -a，-i不够） sudo smartctl -a /dev/nvme0n1重点关注以下NVMe专属字段（SATA盘对应不同名称）：
| SMART ID | 字段名 | 正常值 | 异常征兆 | 我的解读逻辑 |
|---|---|---|---|---|
0x01 | Critical Warning | 0x00 | 非零值（如0x01表示温度过高） | 这是NVMe盘的“总警报灯”，必须为0才能继续看其他指标 |
0x03 | Temperature | 30-70°C | >75°C持续10分钟 | NVMe无散热片时，满载温度易超限，需查/sys/class/nvme/nvme0/nvme0n1/temperature实时值 |
0x04 | Available Spare | 100% | <90%且下降趋势 | 表示备用块剩余比例，低于90%需预警，低于10%盘将只读 |
0x05 | Available Spare Threshold | 10% | 当前值<阈值 | 触发只读保护的临界点 |
0x06 | Percentage Used | 0-100% | >80%且增长快 | 厂商定义的“磨损百分比”，非线性，80%后衰减加速 |
实操心得：
Percentage Used为35%，不代表还能用65%寿命！它基于写入量、擦除次数、坏块增长等多维模型，同一型号不同固件版本算法不同。我见过两块同型号盘，一块Percentage Used=40%但Available Spare=98%，另一块Percentage Used=25%但Available Spare=85%，后者实际更危险。Critical Warning非零时，立即执行sudo smartctl -l error /dev/nvme0n1查错误日志，里面记录了每次错误发生的时间、LBA地址、错误类型（如Invalid Field in Command可能是驱动bug）。
3.5 第五步：性能基线测试（区分硬件瓶颈与系统配置）
# 测顺序读写（模拟大文件拷贝） sudo hdparm -tT /dev/nvme0n1 # 测4K随机读写（模拟数据库IO） sudo fio --name=randread --ioengine=libaio --rw=randread --bs=4k --direct=1 --size=2G --runtime=60 --time_based --group_reporting关键看三组数据：
hdparm -t结果：Timing buffered disk reads: 3546 MB in 3.00 seconds = 1181.59 MB/sec—— 这是内核缓存加速后的读速，反映总线带宽；hdparm -T结果：Timing cached reads: 3214 MB in 2.00 seconds = 1606.52 MB/sec—— 内存缓存读速，用于对比；fio结果：iops=124.5k, bw=498MB/s—— 真实随机读IOPS，若远低于官方标称值（如SN750标称500K IOPS），需查iotop确认是否有其他进程抢占IO。
注意：
hdparm对NVMe盘支持有限，-tT测试结果仅供参考；fio才是金标准。新手常误用dd if=/dev/zero of=/dev/nvme0n1 bs=1M count=1024测速，这会触发TRIM并污染缓存，结果毫无参考价值。
3.6 第六步：错误日志深度分析（定位偶发故障根源）
# 查NVMe错误日志（SATA盘用smartctl -l error） sudo smartctl -l error /dev/nvme0n1 # 查自检日志（确认是否定期执行） sudo smartctl -l selftest /dev/nvme0n1错误日志解读要点：
- 每条记录含
Error Count（累计错误数）、Segment（日志段号）、LBA（逻辑块地址）、Status（错误码） Status=0x4004对应Media Error（介质错误），需结合LBA查文件系统是否损坏；Status=0x4005对应Internal Target Error（内部目标错误），大概率是固件BUG，需升级固件。
实操技巧：
- 若
Error Count持续增长，但Available Spare不变，说明错误发生在已映射的坏块上，固件已自动替换，属可控范围； - 若
Error Count不变，但Available Spare下降，说明备用块被主动预分配，可能因温度过高触发保守策略。
3.7 第七步：综合诊断报告生成（自动化归档）
手动记录所有数据易遗漏，我用一个脚本整合关键信息：
#!/bin/bash DISK="/dev/nvme0n1" echo "=== 硬盘诊断报告 $(date) ===" > report_$(basename $DISK).log echo "【基础属性】" >> report_$(basename $DISK).log sudo smartctl -i $DISK | grep -E "(Device Model|Serial|Firmware|Capacity)" >> report_$(basename $DISK).log echo -e "\n【健康状态】" >> report_$(basename $DISK).log sudo smartctl -a $DISK | grep -E "(Critical Warning|Temperature|Available Spare|Percentage Used)" >> report_$(basename $DISK).log echo -e "\n【性能基线】" >> report_$(basename $DISK).log sudo hdparm -tT $DISK 2>&1 >> report_$(basename $DISK).log echo -e "\n【错误统计】" >> report_$(basename $DISK).log sudo smartctl -l error $DISK | tail -10 >> report_$(basename $DISK).log运行后生成report_nvme0n1.log，可直接邮件发送给团队或存入CMDB系统。这步的价值在于：当三个月后同一块盘出现异常，你只需对比两份报告，一眼看出Available Spare从95%降到88%，Error Count新增3次，无需重新执行全部命令。
4. 高频问题实战排查：从“盘不见了”到“健康但很慢”的12个真实案例
光会命令不够，得知道命令结果异常时怎么办。以下是我在三年运维中整理的12个高频问题，每个都附带现象→根因→验证命令→解决方案四步闭环，拒绝模糊描述：
4.1 现象：lsblk看不到新插入的NVMe SSD
根因：主板M.2插槽物理不兼容（如B450主板只支持PCIe 2.0，但新盘要求PCIe 3.0）或BIOS中禁用了NVMe支持
验证：
lspci | grep -i nvme # 若无输出，说明内核未识别 dmesg | grep -i "nvme\|m2" # 查内核启动日志，常见报错"Unknown device"或"BAR 0: can't allocate"解决方案：
- 进BIOS开启
NVMe Support或Above 4G Decoding选项 - 更换主板M.2插槽（部分主板仅一个插槽支持NVMe）
- 若为笔记本，确认是否需拆机短接特定焊点激活（如某品牌Y系列）
4.2 现象：smartctl -a /dev/sda报错SMART_GET_VERSION failed
根因：SATA控制器工作在IDE模式而非AHCI模式，或USB-SATA转接芯片不支持SMART（如JMicron JMS567）
验证：
cat /sys/class/scsi_host/host*/link_power_management_policy # AHCI模式下应为`min_power` sudo hdparm -I /dev/sda | grep "ATA device" # IDE模式下显示"ATA device", AHCI模式显示"ATAPI device"解决方案：
- BIOS中切换SATA Mode为
AHCI（注意：Windows需提前注入驱动，否则蓝屏） - USB盘改用ASMedia ASM1083主控的硬盘盒（支持SMART透传）
4.3 现象：df -h显示磁盘已满，但du -sh *总和远小于已用空间
根因：已删除文件仍被进程占用（如日志服务未重启），或XFS文件系统预留空间（默认5%）
验证：
lsof +L1 # 列出所有被删除但仍打开的文件 xfs_info /mount/point | grep "imaxpct" # XFS预留空间百分比解决方案：
lsof +L1找到PID，kill -HUP PID重启进程释放空间- XFS下调小预留：
xfs_growfs -r -m 1 /mount/point（设为1%，谨慎操作）
4.4 现象：smartctl -a显示Reallocated_Sector_Ct=0，但系统IO延迟极高
根因：UDMA_CRC_Error_Count（SATA）或Media and Data Integrity Errors（NVMe）持续增长，表明数据线或接口接触不良
验证：
sudo smartctl -a /dev/sda | grep -E "(UDMA_CRC|Media and Data Integrity)" # SATA盘查CRC错误 sudo smartctl -a /dev/nvme0n1 | grep -A5 "Error Information Log" # NVMe查介质错误解决方案：
- 更换SATA数据线（必须用80针屏蔽线）
- 清洁M.2金手指并重插（用橡皮擦轻擦）
- 检查主板SATA口供电电压（万用表测5V/GND间电压，应为4.75-5.25V）
4.5 现象：NVMe盘Percentage Used一年内从5%飙升至60%
根因：后台垃圾回收（GC）策略激进，或文件系统未启用TRIM（如ext4未挂载discard选项）
验证：
mount | grep nvme0n1 # 查是否含`discard`选项 sudo smartctl -a /dev/nvme0n1 | grep "Data Units Written" # 计算年写入量：(当前值-初始值)/365解决方案：
- 临时启用TRIM：
sudo fstrim -v /mnt/data - 永久启用：
/etc/fstab中添加defaults,discard（注意：频繁TRIM影响性能，建议改为fstrim.timer每周执行）
4.6 现象：hdparm -t测速正常，但fio随机读IOPS极低（<1K）
根因：IO调度器配置错误（如NVMe盘误用cfq调度器）或CPU频率限制（节能模式）
验证：
cat /sys/block/nvme0n1/queue/scheduler # 应为`none`（NVMe）或`kyber`（较新内核） cpupower frequency-info | grep "current policy" # 查CPU当前策略解决方案：
- NVMe盘强制使用
none调度器：echo 'none' | sudo tee /sys/block/nvme0n1/queue/scheduler - CPU设为性能模式：
sudo cpupower frequency-set -g performance
4.7 现象：smartctl -a中Temperature显示0xC8（200°C）
根因：固件BUG导致温度传感器读数溢出（常见于某些Intel SSD）
验证：
sudo smartctl -a /dev/nvme0n1 | grep "Temperature" # 若显示`0xC8`或`0xFF`，基本可判定传感器失效 readlink /sys/class/hwmon/hwmon*/device/name # 查真实温度传感器（如`nvme`） cat /sys/class/hwmon/hwmon*/temp1_input # 读取毫摄氏度值解决方案：
- 忽略SMART温度值，改用
hwmon接口读取 - 升级固件（若厂商提供修复版）
4.8 现象：lsblk显示ROTA=1（机械盘），但实际是SSD
根因：内核未正确识别SSD特性（如缺少rotational=0udev规则）
验证：
cat /sys/block/sda/queue/rotational # 应为`0`，若为`1`则被误判 sudo hdparm -I /dev/sda | grep "Nominal Media Rotation Rate" # SSD应显示`Solid State Device`解决方案：
- 手动修正：
echo 0 | sudo tee /sys/block/sda/queue/rotational - 永久生效：创建
/etc/udev/rules.d/60-ssd-rotational.rules，内容KERNEL=="sd[a-z]", ATTR{queue/rotational}="0"
4.9 现象：smartctl -a报告Power_On_Hours=0，但盘已使用两年
根因：某些OEM盘（如戴尔定制版）固件禁用通电时间计数，或NVMe盘未实现此字段
验证：
sudo smartctl -a /dev/nvme0n1 | grep "Power Cycles" # 查电源循环次数，若>1000次，说明确已长期使用解决方案：
- 改用
Power Cycles和Unsafe Shutdowns估算使用强度 - 对OEM盘，查序列号前缀确认生产日期（如WD序列号第4-5位为年份）
4.10 现象：fio测试时iops波动极大（10K~100K）
根因：SSD后台垃圾回收（GC）与前台IO冲突，或文件系统日志模式影响（如ext4的data=ordered）
验证：
iostat -x 1 | grep nvme0n1 # 查`%util`是否100%且`await`>10ms sudo dumpe2fs -h /dev/nvme0n1p1 | grep "Filesystem features" # ext4查日志模式解决方案：
- GC高峰期避开业务：
echo '1' | sudo tee /sys/block/nvme0n1/device/power/control（设为auto） - ext4改用
data=writeback模式（降低日志开销，需权衡数据安全性）
4.11 现象：smartctl -a中Available Spare缓慢下降，但无错误日志
根因：SSD固件主动预分配备用块以应对未来坏块（保守策略），或温度长期偏高加速老化
验证：
sudo smartctl -a /dev/nvme0n1 | grep -E "(Temperature|Available Spare)" # 对比温度与备用块变化率解决方案：
- 加装散热片或改善机箱风道（NVMe盘70°C以上每升高10°C，寿命减半）
- 若
Temperature稳定在40°C但Available Spare月均降1%，联系厂商确认是否批次缺陷
4.12 现象：lsblk显示盘容量为0
根因：分区表损坏或NVMe命名空间未格式化
验证：
sudo fdisk -l /dev/nvme0n1 # 若报错"Unable to open /dev/nvme0n1"，说明命名空间异常 sudo nvme list # 查命名空间状态解决方案：
- NVMe盘：
sudo nvme format /dev/nvme0n1（警告：清空所有数据！） - SATA盘：
sudo fdisk /dev/sda重建分区表（备份MBR：sudo dd if=/dev/sda of=mbr_backup.img bs=512 count=1）
5. 进阶技巧与避坑指南：那些文档里不会写的实战经验
教科书和手册只会告诉你命令怎么用，但不会告诉你为什么这么用、哪里会踩坑。这些经验来自我亲手拆过23块故障盘、重装过17次不同内核、在-20°C冷库和45°C机房都调试过的血泪总结：
5.1 SMART数据不是“健康证明”，而是“风险概率分布图”
很多人把smartctl -a输出当成二值判断：Reallocated_Sector_Ct=0就安全，>0就报废。这是最大误区。真正的解读逻辑是：看指标变化趋势，而非绝对值。举个真实案例：一块三星860 EVO SSD，Reallocated_Sector_Ct从0升到3，但Current_Pending_Sector保持0，UDMA_CRC_Error_Count为0，且Available_Spare仍98%。我连续监测三个月，发现它每月稳定增长1个，没有加速迹象。查三星官方文档，得知该型号固件会在检测到潜在坏块时主动重映射，这是正常的老化过程。最终这块盘又稳定运行了18个月。反观另一块盘，Reallocated_Sector_Ct在一周内从0跳到12，且Current_Pending_Sector同步增长，这就是灾难性故障前兆。所以我的做法是：对每块关键盘建立SMART基线（首次入库时全量采集），之后每周用脚本抓取关键字段，绘制成折线图。只要曲线斜率突变，立即预警。工具很简单：sudo smartctl -a /dev/sda | awk '/Reallocated_Sector_Ct/{print $10}' >> smart_history.log，配合gnuplot画图。
5.2hdparm -I的输出藏着厂商没说的秘密
sudo hdparm -I /dev/sda返回的几百行信息里，有三处关键宝藏常被忽略：
Commands/features:段落：列出该盘支持的高级指令。如看到Write cache，说明可启用写缓存（sudo hdparm -W1 /dev/sda提升性能，但断电可能丢数据）；看到TRIM，确认支持SSD垃圾回收。Security:段落：显示enabled还是frozen。若为frozen，hdparm --user-master u --security-set-pass p /dev/sda会失败，必须先解除冻结（通常需关机重启进BIOS，或热插拔）。Configuration:段落：Logical/Physical Sector size若为4096/4096，说明是4K原生盘，分区对齐必须4K（fdisk中sector单位是512B，需-c关闭DOS兼容模式，用parted创建align=optimal分区）。
5.3 NVMe盘的“假死”比机械盘更难诊断
NVMe盘没有机械寻道，故障表现更隐蔽：不是“咔咔响”，而是iostat显示%util=100%但r/s和w/s为0，dmesg刷屏nvme nvme0: I/O 12345 timeout。此时smartctl一切正常，因为固件层没报错。我的排查铁律是：先查PCIe链路，再查电源，最后查固件。
lspci -vv -s xx:xx.x | grep LnkSta确认链路未降速；sudo ipmitool sdr type "Current"（服务器）或cat /sys/class/power_supply/*/online（桌面）查12V供电是否稳定；- 最后查固件：
sudo nvme id-ctrl /dev/nvme0n1 | grep "fr，对比官网最新固件，升级（sudo nvme fw-download --fw=/path/to/fw.bin /dev/nvme0n1 && sudo nvme fw-commit -s 1 /dev/nvme0n1）。
5.4 别信df，用stat看真实inode消耗
df -i显示inode用尽是常见故障，但新手常误删文件后df -i仍100%，以为没生效。根本原因是：文件被进程打开，删除只是unlink，inode仍被占用。正确做法：
# 查占用inode最多的目录 find /mnt/data -xdev -type f | cut -d "/" -f 1-4 | sort | uniq -c | sort -n # 查具体被哪个进程占用 lsof +L1 /mnt/data | awk '{print $2}' | sort | uniq -c | sort -n曾有个案例：Nginx日志轮转脚本有bug，access.log被重命名后未kill -USR1通知Nginx reopen，导致
