昨天公司的一台NFS服务器遭遇IO居高不下的情况 ，通过iostat查看，io使用率在80%以上，时常还会直接IO飙满，导致NFS的访问异常。重启主机后问题依旧，最后使用iotop查看后，发现主要是jbd2进程在写导致的。具体见下图iotop的结果：
jbd2是ext4文件系统的一部分。为什么会使用如何此的IO。首先想到的是ext4写日志，不过机器自身文的变动（及写或更新）并不大，后来网上查找后发现。ext4文件系统出现过bug，bug原理大致是，文件的写和请求会导致其中一个int型的值不断增大，最后增大到超出了自身的范围 ―― 变成负值 。就会触发该bug ，而想要达到该值并不容易，需要几个月后才会出现。详细的原理不再解释（关键详细的我也看不懂），有兴趣的可以参看如下两篇：
http://blog.donghao.org/2013/03/20/修复ext4日志（jbd2）bug/
http://www.udpwork.com/item/10217.html
在ubuntu论坛上也看到有人反映此类问题： http://ubuntuforums.org/showthread.php?t=2170496
而且以上几个地方都有一个共性的地方，就是提出该情况的时间都是在2013年中旬的时候。所以综合以上信息得出的结果就是这是一个内核ext4文件系统的bug，时间已经过去四五个月的时间。既然当时网上已经有人提供了临时修复补丁 ，官方kernel里也应该做了相应的更新。所以处理该问题的优先级为：
1、yum升级kernel ，重启查看是否有效。（在此之前先要做好备机使用的准备工作）
2、重 装系统分区，完成后重新挂载数据分区。
3、验证临时补丁的可用性。并在现网修复。
最终在使用第一部 yum update更新kernel后，重启主机 。发现IO恢复正常 。jbd2进程的使用恢复到正常水平
之前遇到过 jbd2 引起 IO 高的问题，直接关掉了日志的功能解决的。写了一个文章，但写的不够细。最近又见类似问题，这里重新整理下对 jbd2 的内容。
什么原因会导致jbd2引起IO高？
1. 磁盘满 .
2. 系统 bug ；所知 bug 号： Bug 39072 jbd2writes on disk every few seconds 。
3. 即使没有以上问题。在 ext4 上有一个新加入的参数 barrier ，是用来保证文件系统的完整性的。 [Barrier 解释 ] （ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/block/barrier.txt?id=09d60c701b64b509f328cac72970eb894f485b9e ）。这个值默认是 1 ，即是打开状态。在这个状态下，打开 jbd2 也是会导致性能下降的，这个玩意的设计逻辑就是为了损失掉性能保证文件完整性。
这是个选择题，要么不用它，要么性能差。
但是这个功能不能和设备映射器同时使用，也即是，如果你使用了逻辑卷、软 RAID 、多路径磁盘，则这个值不生效。
jbd2 是个什么？
1. The Journaling Block Device (JBD) provides a filesystem-independent interface for filesystem journaling. ext3, ext4 and OCFS2 areknown to use JBD. OCFS2 starting from Linux 2.6 . 28 [ 1 ] and ext4 use a fork ofJBD called JBD2.[ 2 ]文件系统的日志功能，jbd2是ext4文件系统版本。
检查是否存在jbd2进程
1. [root@7dgroup2~]# ps -ef|grep jbd2 2. root 267 2 0 Aug21 ? 00 : 06 : 17 [jbd2/vda1- 8 ]3. root 24428 22755 0 09 : 48 pts/ 0 00 : 00 : 00 grep --color= auto jbd2
4. [root@7dgroup2~]#检查文件系统的功能
1. [root@7dgroup2~]# dumpe2fs /dev/vda1 | grep has_journal2. dumpe2fs 1.42 . 9 ( 28 - Dec - 2013 )
3. Filesystem features: has_journalext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
4. [root@7dgroup2~]#存在has_journal。
问题现象
在使用iotop看的时候，会有如下信息出现。
1. Total DISK READ: 46.15 M/s | Total DISK WRITE: 8.24 K/s
2. TID PRIO USER DISKREAD DISK WRITE SWAPIN IO> COMMAND
3. 4036 be/ 4 search 56.87 K/s 26.45 K/s 0.00 % 87.64 % [jbd2/dm- 0 - 4 ]解决方案一
关闭日志功能。
1. tune2fs -ojournal_data_writeback /dev/vda1
2. tune2fs -O "^has_journal" /dev/vda1
3. e2fsck -f /dev/vda1
如果使用tune2fs时候，提示disk正在mount，如果是非系统盘下，你可以使用
1. fuser -km /home # 杀死所有使用/home下的进程
2. umount /dev/vda1 #umount
之后在使用上面的命令进行移除has_journal。
解决方案二
如果是bug的话，可以用这种方式解决。如果是不是bug，这种方式也解决不了，所以要先判断下引起问题的原因再选择解决方案。
升级系统内核。
1. yum updatekernel
解决方案三
禁用Barrier的同时修改commit的值。这个方式可以解决barrier引起的性能下降，但是解决不了系统bug的问题。
修改commit值，降低文件系统提交次数或者禁用barrier特性； 建议文件系统参数为:
1. defaults,noatime,nodiratime,barrier= 0 ,data=writeback,commit= 60
然后重新挂载。
1. mount -o remount,commit= 60 /data
其中barrier=0是禁用barrier特性,commit=60是减少提交次数。 减少提交次数只能缓解。
解决方案四
如果不是bug，并且不想禁用barrier时，用此方式缓解。
想尽办法降低IO，缓解IO压力。这种方式也会导致其他系统资源用不上去。比如说在mysql中把syncbinlog加大，同时将innodbflushlogattrxcommit增加。 比如说在应用中减少IO的读写。
bug 的根源
在之前的版本中出现问题有一个原因是ext4文件系统出现bug。 这个bug出现的比较早了，我看kerneltracker里最早的信息是2011年，如果如果是用的老版本，我建议先做升级。如果没有升级条件，只能用上面的关闭日志功能的解决方案。
bug 原因是： 在这段代码中：
1. int __jbd2_log_start_commit( journal_t *journal, tid_t target)
2. {
3. /*
4. * Are we alreadydoing a recent enough commit?
5. */
6. if (!tid_geq(journal->j_commit_request,target)) {
7. /*
8. * We want a new commit: OK, mark the request and wakup the
9. * commit thread. We do _not_ do the commit ourselves.
10. */
11. journal->j_commit_request = target;
12. jbd_debug( 1 , "JBD:requesting commit %d/%dn" ,
13. journal->j_commit_request,
14.