05 2011存档
线上有应用使用了ext4文件系统的no journal模式(mkfs.ext4 -o ^has_journal /dev/sda)，最近反馈有目录丢失，dmesg里报错：
EXT4-fs error (device sda7): ext4_lookup: deleted inode referenced: 26214657
上周五我们用e2image把线上的硬盘镜像出来，然后fsck sda.img -fy对镜像文件进行修复，发现这些corrupt的目录（54个子目录）在inode table对应的内容全为空（不仅是nlink为0，连 ctime/atime/mtime等都是空），这不是rmdir能造成的（rmdir会修改 dtime而不是清空inode table里对应的那一整个inode），所以此bug应该不是rmdir造成，这与线上的现象一致（从同事的反馈，线上应用只会在硬盘快满时才rmdir，而出现bug的时候硬盘空间还很宽裕）。
于是我们怀疑这种全空是由类似memset的内核代码操作造成的，便寻找 fs/ext4/ 下调用了memset的所有地方，其中 fs/ext4/inode.c 里 __ext4_get_inode_loc 函数里的一句尤其刺眼：
memset(bh->b_data, 0, bh->b_size);
这一句的调用时机是：当前inode如果是它所在inode table的buffer里唯一的一个 inode，则调用memset。线上corrupt的目录都是它父目录下的第255个目录，它们确实是满足这个调用时机的，故而此处嫌疑最大。问题很可能出现在mkdir上。
根据这个判断我们设计了一个重现方法：
首先，启动一个程序，重复的创建目录和文件（模拟线上squid创建的那个目录结 构），为了增加race，10个线程同时去mkdir，然后再删 除全部目录，再remount 硬盘，周而复始。
另外，还启动一个程序，重复的让系统drop_cache
最后，启动多个nbench（一个测试CPU和内存速度的测试工具），增加系统的CPU压力
使用这个重现方法，三管并发，在开发机上不到1小时这个bug便出现了。
于是我们在kernel source里插入褉子，最后追踪到是系统在writeback时会调用 ext4_write_inode ，而它里面错误的调用了 ext4_get_inode_loc (应该调 __ext4_get_inode_loc且第三个参数为0)，memset掉了 inode table buffer_head的内容，回头再看upstream的code，这个bug原来已经被google的同学在一年前fix了：(commit 8b472d739b2ddd8ab7fb278874f696cd95b25a5e)。
ext4的no journal本来就是google贡献的，估计他们已经用开了，所以早就已经解决了这个问题，而我们的kernel tree上还没有这个fix。
有同事问到我：使用cp命令时，如果发现要被覆盖的文件（二进制可执行文件）正在运行，cp会报错，cp命令是怎么知道该文件正在执行的？
我第一个想到的是：可能ioctl可以检查文件。可惜我猜错了，看了一下cp的源码，原来如果一个文件正在运行，另一个进程再open以获得写权限的话，这个open本身就会失败，返回-1，errno为ETXTBSY。
那么cp -f 为什么又可以？因为cp -f会先把目标文件（要被覆盖的文件）删掉，然后将源文件rename为目标文件名。
从内核代码看，当运行一个二进制文件时
sys_execve()
do_execve()
open_exec()
deny_write_access()
这里的deny_write_access会把文件对应inode的i_writecount成员减1，通常i_writecount的值就变成-1了（初始为0）
这时候再有进程想以写模式open：
do_sys_open()
do_filp_open()
path_openat()
do_last()
nameidata_to_filp()
__dentry_open()
__get_file_write_access()
get_write_access()
get_write_access会发现inode的i_writecount成员为负数了，所以直接返回 -ETXTBSY
