linux不记录分区对齐错误日志，因其属静默性能缺陷；唯一权威验证是sudo parted /dev/sda align-check optimal 1，返回“1 aligned”才确认真正对齐，否则即使fdisk显示start=2048也无效。
Linux本身不记录“分区对齐错误”的日志——它不会在 dmesg、/var/log/kern.log 或 journalctl 里主动报“你没对齐”。对齐问题属于静默性能缺陷，系统照常挂载、读写，只在底层 I/O 效率上打折。
为什么 dmesg 和 journalctl 查不到对齐错误
内核不校验或告警分区对齐状态；dmesg 可能显示 I/O 超时、重试或硬件错误，但和对齐无直接因果关系；journalctl -k 同样只反映驱动层事件，而非逻辑扇区偏移合规性。
- 执行
sudo dmesg | grep -i "error\|fail\|sector"返回空或无关硬盘坏道信息，不能说明对齐正常 -
journalctl -u systemd-udevd可能记录设备探测，但不含对齐判断逻辑 - 即使
parted -l显示Aligned: no，也不会写入日志——这是工具运行时计算结果，非内核事件
用 iostat -x 找对齐异常的间接证据
未对齐最典型的运行时表现是：单次逻辑 I/O 请求被迫拆成多次物理访问，导致平均请求大小（avgrq-sz）持续偏高且波动异常。
- 运行
iostat -x 1（每秒刷新），观察目标设备（如sda）的avgrq-sz列： - 若稳定在
8.0或更高（如16.0、24.0），而你的应用是小块随机读写（如数据库4K请求），大概率未对齐 - 对比已知对齐的同型号盘：
avgrq-sz应接近4.0（512B × 4 = 2048B）或8.0（512B × 8 = 4096B）整数倍，且方差小 - 注意排除缓存干扰：测试前用
echo 3 > /proc/sys/vm/drop_caches，并用fio发起直写（--direct=1）负载
检查内核暴露的底层对齐参数
真正决定对齐是否成立的，是设备向内核报告的 optimal_io_size、alignment_offset 和 physical_block_size。这些值被 parted align-check 使用，也影响 I/O 调度器行为。
- 查关键路径：
cat /sys/block/sda/queue/optimal_io_size（应为0或4096等 4K 倍数） -
cat /sys/block/sda/alignment_offset（常见为0，RAID 卡可能返回2048） -
cat /sys/block/sda/queue/physical_block_size（SSD/NVMe 多为4096） - 若
optimal_io_size为0，说明设备未声明最优对齐，此时parted align-check optimal 1会失败，需依赖fdisk -l的Start % 8 == 0规则
parted align-check optimal 是唯一带结论的验证命令
它不是查日志，而是实时计算：用上述三个 sysfs 值推导理论最优起始扇区，并比对实际分区位置。这才是你能拿到的最接近“错误判定”的输出。
- 运行：
sudo parted /dev/sda align-check optimal 1（1是分区号） - 返回
1 aligned→ 满足当前设备约束 - 返回
1 not aligned→ 真实对齐失败，不管fdisk -l的Start看起来多整齐 - 常见陷阱：NVMe 设备用
/dev/nvme0n1p1执行会报错，必须指定裸盘/dev/nvme0n1 - 如果提示
Alignment offset is not known，说明alignment_offset读取失败，需检查驱动或硬件文档
真正麻烦的从来不是“怎么看出错了”，而是“明明 Start=2048 还被 align-check 打脸”——这时候得去翻 RAID 卡手册或云厂商的存储池配置，底层错位，上层再规范也没用。
