@Osk 哥们，我一个核至少三个开发板在跑…

@yao990 看你 43 楼的日志还是有 inode 会丢了的，去 lost+found 找

这些 inode 谁也不知道是什么文件，你胆大就搞，不敢就放在那。
设备忙是因为还有文件描述符没有关闭，fuser
不用每一步就找我确认一下，我说话不用付什么责任的，操作的人还是你

你先 dd 备份一下啊

谁能知道丢多少…

我是觉得没啥问题了… 你可以 彻底 umount 掉 然后 repair

到不是日志，我怕你把 ag 租和 inode 搞丢了。
还有输入输出错误就再看 dmesg,实在搞不定就 dd 然后 repair

要是想完全和以前一样，不是不能，但是超级难。
要是能忍受一点点的数据丢失那好办了

@reus 他 lazy umount 的 之前压根没 repair 还有救

dm-2: rw=7217, want=6444519751, limit=5862637568
把硬盘再 lv 再扩大吧，没有原来的的大。
还有你的数据大概率找不全了

[242061.505790] attempt to access beyond end of device

[242061.505799] dm-2: rw=7217, want=6444519751, limit=5862637568

[242061.505818] XFS (dm-2): metadata I/O error: block 0x1801f9145 ("xlog_iodone") error 5 numblks 64

[242061.505825] XFS (dm-2): xfs_do_force_shutdown(0x2) called from line 1222 of file fs/xfs/xfs_log.c. Return address = 0xffffffffc053ae20

[242061.505836] XFS (dm-2): Log I/O Error Detected. Shutting down filesystem

[242061.505839] XFS (dm-2): Please umount the filesystem and rectify the problem(s)

[242239.788000] sdc: sdc1

从你的 log 里没看到任何 umount 的操作，先 umount 再 xfs_repair

输入输出错误，把 dmesg 打出来我看一眼

你贴一下报错

等灵感

应该是姿势问题
sysroot libc 交叉编译工具链都用对了么

我们服务器上的 raid 卡有个奇怪的 raid 模式 要求至少五块盘 四个主用一个备用 要是六块就两备用。最大 8 个盘也是两个备用。
他明确说了不叫 Raid 5。

@yanaraika 其实我并不觉得写未定义行为的代码，就是问题，更谈不上是严重的问题。
我们这套代码用了十多年了，好多东西都是静态库直接分发的，能 O3 的部分早就 O3 了。
历史包袱有多重，你想不到的兄弟，就这样上边还嫌需求开发的慢呢，本来 O2 能跑，就为了一点虚无缥缈的性能，你非要换成 O3，线上炸了，这个责任谁接，炸了的这部分代码和你一点关系都没有？ O2 加上特殊的代码写法，能达到我们要的性能，何必换呢？
再说 O3 又不是一定会带来性能提升，我贴一段话：

-O3 has several disadvantages:

First of all it often produces slower code than -O2 or -Os. Sometimes it produces longer code due to loop unrolling which may be in fact slower due to worse cache performance of code.
As it was said it sometimes produces wrong code. It may be either due to error in optimalization or error in code (like ignoring strict aliasing). As kernel code sometimes is and sometimes have to be 'smart' I'd say it is possible that some kernel developer made some error. I experienced various strange problems, like crashing of userspace utilities, when I compiled kernel with gcc 4.5 which at that point was stable. I still use gcc 4.4 for kernel and several selected userspace utilities due to various bugs. The same may apply for -O3.
I don't think it offers much benefit for the Linux kernel. The kernel does not do heavy computations and in places it does, it is optimized with assembly. -O3 flag will not change the cost of context switching or speed of I/O. I don't think something like <0.1% speedup of overall performance is worth it.

只要是能稳定，性能不差，O2 又能怎样。
招不到靠谱的人，兄弟，不是说这十几年里每个人都是会写 well-defined 的代码，要是人人都这样，那还要做什么测试，直接发布就得了。
理想很丰满啊哥们。

@yanaraika 我还是那句话，有的事情远比你我在这里讨论的情况，还要复杂