先把当时的情况摆出来。CentOS 7.9 的日志盘按网上参数挂成 data=writeback，barrier 也一起关了，机房一次瞬时掉电之后，好几个已经写完的日志文件大小是 0，另一些末尾缺了几百行。
排查方向其实有限，先把可能性排一排。writeback 只保证元数据一致，数据块可能比元数据晚落盘。少数情况下是barrier=0 关掉了写屏障，磁盘缓存里的顺序完全不受控。
还有一种情况，应用写完没有 fsync，只依赖内核三十秒的回写周期。另外，云盘的写缓存没有掉电保护，掉电瞬间缓存里的数据直接没了。
先确认当前挂载参数
findmnt -no OPTIONS /dev/vdb1随后改回 ordered 并打开屏障
mount -o remount,ordered,barrier=1 /dev/vdb1接着看关键进程有没有做落盘调用
strace -f -e trace=fsync,fdatasync -p $(pgrep -f logwriter) 2>&1 | head等前面都确认过，再检查文件系统本身有没有记错
dumpe2fs -h /dev/vdb1 | grep -E 'Filesystem state|Errors behavior'怎么算真的好了，看的是同一批现象。findmnt 显示 ordered 和 barrier=1，日志文件在进程被强杀后内容完整，测试写入不再出现空文件。
补一句。writeback 换来的是吞吐，代价是掉电必丢最近的数据；日志类业务至少要用 ordered 加应用层 fsync，指望 remount 补救已经丢掉的块并不现实。报错文案容易误导，真正的原因往往在相邻那一层的日志里。