我在服务器中看到以下消息/var/log/messages
。它们看起来像堆栈跟踪,并且前面没有任何叙述(例如“某某出了问题”)。
我几乎确信它们与我遇到的 I/O 问题有关,但了解这些消息到底是什么以及是什么触发了它们会很有帮助。
1 月 25 日 14:56:58 主机名内核:[15321.586145] master D 000000010016bfbb 0 2753 1 0x00000004 1 月 25 日 14:56:58 主机名内核:[15321.586150] ffff88030d053a78 0000000000000086 00000000ffffffff 0000000000015980 1 月 25 日 14:56:58 主机名内核:[15321.586156] ffff88030d053fd8 0000000000015980 ffff88030d053fd8 ffff88030dedc4a0 1 月 25 日 14:56:58 主机名内核:[15321.586161] 0000000000015980 0000000000015980 ffff88030d053fd8 0000000000015980 1 月 25 日 14:56:58 主机名内核:[15321.586166] 调用跟踪: 1 月 25 日 14:56:58 主机名内核:[15321.586176] [] do_get_write_access+0x2ed/0x5b0 1 月 25 日 14:56:58 主机名内核:[15321.586182] [] ?wake_bit_function+0x0/0x40 1 月 25 日 14:56:58 主机名内核:[15321.586189] [] jbd2_journal_get_write_access+0x31/0x50 1 月 25 日 14:56:58 主机名内核:[15321.586192] [] __ext4_journal_get_write_access+0x38/0x70 1 月 25 日 14:56:58 主机名内核:[15321.586195] [] ext4_reserve_inode_write+0x73/0xa0 1 月 25 日 14:56:58 主机名内核:[15321.586197] [] ?jbd2_journal_start+0xb5/0x100 1 月 25 日 14:56:58 主机名内核:[15321.586199] [] ext4_mark_inode_dirty+0x4c/0x1d0 1 月 25 日 14:56:58 主机名内核:[15321.586200] [] ?ext4_journal_start_sb+0xf8/0x130 1 月 25 日 14:56:58 主机名内核:[15321.586202] [] ext4_dirty_inode+0x40/0x60 1 月 25 日 14:56:58 主机名内核:[15321.586205] [] __mark_inode_dirty+0x42/0x1d0 1 月 25 日 14:56:58 主机名内核:[15321.586207] [] file_update_time+0xfb/0x180 1 月 25 日 14:56:58 主机名内核:[15321.586210] [] pipe_write+0x32b/0x670 1 月 25 日 14:56:58 主机名内核:[15321.586212] [] do_sync_write+0xda/0x120 1 月 25 日 14:56:58 主机名内核:[15321.586215] [] ?apparmor_file_permission+0x18/0x20 1 月 25 日 14:56:58 主机名内核:[15321.586218] [] ? security_file_permission+0x16/0x20 1 月 25 日 14:56:58 主机名内核:[15321.586220] [] vfs_write+0xb8/0x1a0 1 月 25 日 14:56:58 主机名内核:[15321.586221] [] sys_write+0x51/0x80 1 月 25 日 14:56:58 主机名内核:[15321.586223] [] ? sys_poll+0x7c/0x110 1 月 25 日 14:56:58 主机名内核:[15321.586226] [] system_call_fastpath+0x16/0x1b 1 月 25 日 14:56:58 主机名内核:[15321.586237] qmgr D 000000010016bfbb 0 2756 2753 0x00000004 1 月 25 日 14:56:58 主机名内核:[15321.586239] ffff8802f6cefa98 0000000000000082 ffff880200000000 0000000000015980 1 月 25 日 14:56:58 主机名内核:[15321.586241] ffff8802f6ceffd8 0000000000015980 ffff8802f6ceffd8 ffff88030d3c44a0 1 月 25 日 14:56:58 主机名内核:[15321.586243] 0000000000015980 0000000000015980 ffff8802f6ceffd8 0000000000015980 1 月 25 日 14:56:58 主机名内核:[15321.586245] 调用跟踪: 1 月 25 日 14:56:58 主机名内核:[15321.586247] [] do_get_write_access+0x2ed/0x5b0 1 月 25 日 14:56:58 主机名内核:[15321.586249] [] ?wake_bit_function+0x0/0x40 1 月 25 日 14:56:58 主机名内核:[15321.586251] [] jbd2_journal_get_write_access+0x31/0x50 1 月 25 日 14:56:58 主机名内核:[15321.586253] [] __ext4_journal_get_write_access+0x38/0x70 1 月 25 日 14:56:58 主机名内核:[15321.586255] [] ext4_reserve_inode_write+0x73/0xa0 1 月 25 日 14:56:58 主机名内核:[15321.586257] [] ?jbd2_journal_start+0xb5/0x100 1 月 25 日 14:56:58 主机名内核:[15321.586258] [] ext4_mark_inode_dirty+0x4c/0x1d0 1 月 25 日 14:56:58 主机名内核:[15321.586260] [] ?ext4_journal_start_sb+0xf8/0x130 1 月 25 日 14:56:58 主机名内核:[15321.586263] [] ? ep_poll_callback+0xbb/0xf0 1 月 25 日 14:56:58 主机名内核:[15321.586265] [] ext4_dirty_inode+0x40/0x60 1 月 25 日 14:56:58 主机名内核:[15321.586266] [] __mark_inode_dirty+0x42/0x1d0 1 月 25 日 14:56:58 主机名内核:[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 1 月 25 日 14:56:58 主机名内核:[15321.586275] [] ?default_spin_lock_flags+0x9/0x10 1 月 25 日 14:56:58 主机名内核:[15321.586276] [] ?ep_poll+0xab/0x2a0 1 月 25 日 14:56:58 主机名内核:[15321.586278] [] ?apparmor_file_permission+0x18/0x20 1 月 25 日 14:56:58 主机名内核:[15321.586280] [] ? security_file_permission+0x16/0x20 1 月 25 日 14:56:58 主机名内核:[15321.586282] [] vfs_read+0xb5/0x1a0 1 月 25 日 14:56:58 主机名内核:[15321.586283] [] sys_read+0x51/0x80 1 月 25 日 14:56:58 主机名内核:[15321.586285] [] ? sys_epoll_wait+0x96/0xe0 1 月 25 日 14:56:58 主机名内核:[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
答案1
具体来说,ext4 在将数据写入日志时遇到了困难。我对 ext3 的经验是,日志用于将您即将提交的元数据写入安全的地方,这样在系统崩溃时至少可以撤消。由于写入日志是一项非关键但重要的功能,因此它可能只是出现故障并继续运行。由于系统当时没有崩溃,因此您只会在 ext4 内核模块遇到日志问题期间遇到延迟。
那么为什么文件系统在处理日志时会遇到问题呢?看看下面的问题,看看它们是否能激发更多的想法:
- 您是否将日志放在了有问题或繁忙度百分比相当高的单独设备上?
- 如果磁盘不是本地的(iSCSI、ATAoE 或光纤通道),您是否遇到了通信问题,或者您能否证明没有遇到问题?
- 您上次运行 fsck 检查完整性错误是什么时候?
- 如果它是单个内部驱动器,您是否尝试运行制造商的诊断工具以确保磁盘仍按规格运行?
- 对于内置驱动器,是否启用了 SMART 并且你使用工具吗观看设备?