本文由作者朱益軍授權網易雲社區發布。
背景
維護巡檢雲主機時，發現有一台運行redis的雲主機狀態顯示維護中，登錄該實例查看，系統盤變成readonly。本文簡單分析該問題出現原因，並為運維人員提供常見處理方法及建議。
故障分析
查看雲主機dmesg信息發現，系統運行過程中python進程發生segfault，隨后vda（雲主機配置virtio-blk，故盤符顯示為vda）系統盤I/O error。
[8349644.226151] Clock: inserting leap second 23:59:60 UTC
[8744049.152007] The scan_unevictable_pages sysctl/node-interface has been disabled for lack of a legitimate use case. If you have one, please send an email to linux-mm@kvack.org.
[30940223.794815] python[28313]: segfault at 58 ip 00000000004aa8c7 sp 00007f2b44a2f560 error 4 in python2.7[400000+257000]
[42731185.176179] end_request: I/O error, dev vda, sector 12590864
[42731185.468491] EXT4-fs error (device vda1): __ext4_get_inode_loc:3697: inode #403168: block 1573613: comm updatedb.mlocat: unable to read itable block
[42731185.471307] Aborting journal on device vda1-8.
[42731185.472359] journal commit I/O error
[42731185.473183] EXT4-fs error (device vda1): ext4_journal_start_sb:327: Detected aborted journal
[42731185.474761] EXT4-fs (vda1): Remounting filesystem read-only
[42731185.588205] EXT4-fs (vda1): Remounting filesystem read-only
[42731185.750067] end_request: I/O error, dev vda, sector 12590872
[42731185.751578] EXT4-fs error (device vda1): __ext4_get_inode_loc:3697: inode #403173: block 1573614: comm updatedb.mlocat: unable to read itable block
[42817852.384073] EXT4-fs (vda1): error count since last fsck: 4
[42817852.384077] EXT4-fs (vda1): initial error at time 1517610339: __ext4_get_inode_loc:3697: inode 403168: block 1573613
[42817852.384081] EXT4-fs (vda1): last error at time 1517610340: __ext4_get_inode_loc:3697: inode 403173: block 1573614
[42904359.904061] EXT4-fs (vda1): error count since last fsck: 4
[42904359.904065] EXT4-fs (vda1): initial error at time 1517610339: __ext4_get_inode_loc:3697: inode 403168: block 1573613
[42904359.904069] EXT4-fs (vda1): last error at time 1517610340: __ext4_get_inode_loc:3697: inode 403173: block 1573614
[42990867.424056] EXT4-fs (vda1): error count since last fsck: 4
[42990867.424060] EXT4-fs (vda1): initial error at time 1517610339: __ext4_get_inode_loc:3697: inode 403168: block 1573613
[42990867.424064] EXT4-fs (vda1): last error at time 1517610340: __ext4_get_inode_loc:3697: inode 403173: block 1573614基本可確定是業務把系統盤寫壞了。通常發生該問題的場景有二：
一、雲主機和宿主機IO繁忙，雲主機的IO請求得不到及時的響應，從而產生磁盤IO錯誤，為了保護磁盤數據會remount分區為只讀；
二、雲主機被強制關機，導致磁盤出現文件系統錯誤故障。
故障處理
通常的解決方法是重啟系統以root用戶進入單用戶模式，運行fsck.ext3 –y /dev/vda（如果是ext4使用fsck.ext4修復），/dev/vda是系統/根分區。修復完reboot進入系統。以debian系統為例：
1、重啟系統，grub菜單會出現正常啟動和修復模式（recovery mode）啟動兩個菜單項，選擇修復模式啟動；
2、進入修復模式，運行fsck工具修復；
3、重啟進入正常模式啟動。
注意：
1、運維人員在重啟雲主機之前盡量先收集一些關鍵的日志，如/var/log下面的一些日志、dmesg等，有條件也要收集宿主機的日志；
2、fsck是Linux內核自帶工具，它不僅可以對文件系統進行掃描，還能修正文件系統的一些問題。fsck掃描文件系統時一定要在單用戶模式、修復模式或把設備umount后進行。建議在單用戶模式下運行。如果掃描正常運行中的系統，會造成系統文件損壞,需要root權限執行。
建議與思考
1、當前開發要定位問題，需要申請宿主機權限等流程，無法及時上去定位；
2、當前雲主機的日志收集功能尚不完善，呈現的日志比較雜、亂、實用性不高，需要適當進行修改調整。另外，運維人員也不知道要收集哪些日志可支撐開發定位；
開發正在考慮開發一個一鍵式日志收集工具，集成到版本中，定期采集系統數據並歸檔，或者在發生故障時，由運維先收集分析，再交給開發定位，這樣效率會高一些。
更多網易技術、產品、運營經驗分享請訪問網易雲社區。
相關文章：
【推薦】 MongoDB復制集與Raft協議異同點分析