/var/log/messages 中的神秘堆栈跟踪

/var/log/messages 中的神秘堆栈跟踪

我在服务器中看到以下消息/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 并且你使用工具吗观看设备?

相关内容