我在服务器的/var/log/messages看到以下/var/log/messages 。 他们看起来像堆栈痕迹，并没有任何叙述（例如“这样那样的错误”）之前。
我几乎可以肯定它们与我正在经历的I / O问题有关，但是明白这些消息究竟是什么以及是什么触发它们将是有益的。
Jan 25 14:56:58 hostname kernel：[15321.586145] master D 000000010016bfbb 0 2753 1 0x00000004 Jan 25 14:56:58 hostname kernel：[15321.586150] ffff88030d053a78 0000000000000086 00000000ffffffff 0000000000015980 Jan 25 14:56:58 hostname kernel：[15321.586156] ffff88030d053fd8 0000000000015980 ffff88030d053fd8 ffff88030dedc4a0 Jan 25 14:56:58 hostname kernel：[15321.586161] 0000000000015980 0000000000015980 ffff88030d053fd8 0000000000015980 Jan 25 14:56:58 hostname kernel：[15321.586166] Call Trace： Jan 25 14:56:58 hostname kernel：[15321.586176] [] do_get_write_access + 0x2ed / 0x5b0 Jan 25 14:56:58 hostname kernel：[15321.586182] []？ wake_bit_function +为0x0 / 0x40的 Jan 25 14:56:58 hostname kernel：[15321.586189] [] jbd2_journal_get_write_access + 0x31 / 0x50 Jan 25 14:56:58 hostname kernel：[15321.586192] [] __ext4_journal_get_write_access + 0x38 / 0x70 1月25日14:56:58主机名内核：[15321.586195] [] ext4_reserve_inode_write + 0x73 / 0xa0 Jan 25 14:56:58 hostname kernel：[15321.586197] []？ jbd2_journal_start + 0xB5执行/ 0x100的 Jan 25 14:56:58 hostname kernel：[15321.586199] [] ext4_mark_inode_dirty + 0x4c / 0x1d0 Jan 25 14:56:58 hostname kernel：[15321.586200] []？ ext4_journal_start_sb + 0xF8的/量0x130 Jan 25 14:56:58 hostname kernel：[15321.586202] [] ext4_dirty_inode + 0x40 / 0x60 Jan 25 14:56:58 hostname kernel：[15321.586205] [] __mark_inode_dirty + 0x42 / 0x1d0 Jan 25 14:56:58 hostname kernel：[15321.586207] [] file_update_time + 0xfb / 0x180 Jan 25 14:56:58 hostname kernel：[15321.586210] [] pipe_write + 0x32b / 0x670 1月25日14:56:58主机名内核：[15321.586212] [] do_sync_write + 0xda / 0x120 Jan 25 14:56:58 hostname kernel：[15321.586215] []？ apparmor_file_permission +为0x18 / 0x20的 Jan 25 14:56:58 hostname kernel：[15321.586218] []？ security_file_permission + 0x16 / 0x20的 1月25日14:56:58主机名内核：[15321.586220] [] vfs_write + 0xb8 / 0x1a0 Jan 25 14:56:58 hostname kernel：[15321.586221] [] sys_write + 0x51 / 0x80 Jan 25 14:56:58 hostname kernel：[15321.586223] []？ sys_poll + 0x7c /量0x110 Jan 25 14:56:58 hostname kernel：[15321.586226] [] system_call_fastpath + 0x16 / 0x1b Jan 25 14:56:58 hostname kernel：[15321.586237] qmgr D 000000010016bfbb 0 2756 2753 0x00000004 Jan 25 14:56:58 hostname kernel：[15321.586239] ffff8802f6cefa98 0000000000000082 ffff880200000000 0000000000015980 Jan 25 14:56:58 hostname kernel：[15321.586241] ffff8802f6ceffd8 0000000000015980 ffff8802f6ceffd8 ffff88030d3c44a0 Jan 25 14:56:58 hostname kernel：[15321.586243] 0000000000015980 0000000000015980 ffff8802f6ceffd8 0000000000015980 1月25日14:56:58主机名内核：[15321.586245]呼叫跟踪： Jan 25 14:56:58 hostname kernel：[15321.586247] [] do_get_write_access + 0x2ed / 0x5b0 Jan 25 14:56:58 hostname kernel：[15321.586249] []？ wake_bit_function +为0x0 / 0x40的 Jan 25 14:56:58 hostname kernel：[15321.586251] [] jbd2_journal_get_write_access + 0x31 / 0x50 Jan 25 14:56:58 hostname kernel：[15321.586253] [] __ext4_journal_get_write_access + 0x38 / 0x70 Jan 25 14:56:58 hostname kernel：[15321.586255] [] ext4_reserve_inode_write + 0x73 / 0xa0 Jan 25 14:56:58 hostname kernel：[15321.586257] []？ jbd2_journal_start + 0xB5执行/ 0x100的 1月25日14:56:58主机名内核：[15321.586258] [] ext4_mark_inode_dirty + 0x4c / 0x1d0 Jan 25 14:56:58 hostname kernel：[15321.586260] []？ ext4_journal_start_sb + 0xF8的/量0x130 Jan 25 14:56:58 hostname kernel：[15321.586263] []？ ep_poll_callback +为0xBB / 0XF0 1月25日14:56:58主机名内核：[15321.586265] [] ext4_dirty_inode + 0x40 / 0x60 Jan 25 14:56:58 hostname kernel：[15321.586266] [] __mark_inode_dirty + 0x42 / 0x1d0 Jan 25 14:56:58 hostname kernel：[15321.586268] [] touch_atime + 0x135 / 0x180 1月25日14:56:58主机名内核：[15321.586270] [] pipe_read + 0x2b4 / 0x4a0 1月25日14:56:58主机名内核：[15321.586272] [] do_sync_read + 0xda / 0x120 Jan 25 14:56:58 hostname kernel：[15321.586275] []？ default_spin_lock_flags + 0x9 / 0x10的 Jan 25 14:56:58 hostname kernel：[15321.586276] []？ ep_poll +是0xAB / 0x2a0 Jan 25 14:56:58 hostname kernel：[15321.586278] []？ apparmor_file_permission +为0x18 / 0x20的 Jan 25 14:56:58 hostname kernel：[15321.586280] []？ security_file_permission + 0x16 / 0x20的 Jan 25 14:56:58 hostname kernel：[15321.586282] [] vfs_read + 0xb5 / 0x1a0 Jan 25 14:56:58 hostname kernel：[15321.586283] [] sys_read + 0x51 / 0x80 Jan 25 14:56:58 hostname kernel：[15321.586285] []？ sys_epoll_wait + 0x96 / 0xe0的 Jan 25 14:56:58 hostname kernel：[15321.586287] [] system_call_fastpath + 0x16 / 0x1b
内核是Linux hostname 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 02:41:37 UTC 2010 x86_64 GNU/Linux
它特别看起来ext4正在向日记写入数据方面遇到困难。 我使用ext3的经验是，这个日志用于将你将要提交的元数据写入一个安全的地方，在系统崩溃的情况下至less可以撤消它。 由于写日记是一个非关键的，虽然重要的function，它可能只是一个哎呀，滚来滚去。 由于系统当时没有崩溃，所以在ext4内核模块出现问题时，您只会遇到延迟。
那么为什么文件系统在杂志上遇到麻烦？ 看看下面的问题，看看他们是否引发了更多的想法：