我是如何分析io_submit 出現無效描述符的錯誤的

現象

在本人的系統軟件中調用io_submit提交IO請求，長時間運行後會返回不爲1，並且還伴隨着 Bad File descripotr 錯誤。檢查了提交先後文件描述符的值，都是對的；檢查了文件是否存在，文件打開先後都是存在的。那到底什麼緣由呢？

分析

首先的找到問題的直接緣由，這就須要理解io submit 的錯誤碼。

錯誤碼的含義

經過 man io_submit 很容易看到：

io_submit returns the number of iocbs submitted and 0 if nr is zero.

ERRORS
       EINVAL The aio_context specified by ctx_id is  invalid.   nr  is  less  than  0.  The  iocb  at
              *iocbpp[0]  is  not  properly initialized, or the operation specified is invalid for the
              file descriptor in the iocb.

       EFAULT One of the data structures points to invalid data.

       EBADF  The file descriptor specified in the first iocb is invalid.

       EAGAIN Insufficient resources are available to queue any iocbs.

幾種可能致使的緣由

針對io submit 返回的EBADF， 常見的錯誤包括：

• 傳入的IOCB 中的文件描述符沒有對應一個文件；
• 傳入的IOCB中的文件描述符對應的文件後來被刪去了；
• 傳入的IOCB 中的文件描述符沒有讀寫權限；
• 傳入的IOCB中的文件描述符對應的文件後來被關閉了。

爲此，筆者進行了下面的工做來檢查是不是上面的錯誤：

• 檢查提交先後IOCB中的文件描述符字段是否變化：沒有變化，排除這個問題；
• 檢查傳入的IOCB中的文件描述符對應的文件是否存在：提交先後一直存在；
• 檢查對應的文件在IO請求提交先後是否可讀可寫：可讀可寫，排除這個問題；
• 檢查傳入的IOCB中的文件描述符對應的文件在提交過程當中是否會被關閉：經過深刻閱讀相關模塊代碼發如今當前系統上，爲了不重複打開相同文件，有一個文件描述符 cache 管理文件描述符，這個cache 容量有限，每新打開一個文件的時候，cache size就會加1；當達到容量上限的時候，會把最近不使用的文件關掉。若是這個時候，有在飛的io submit 請求，那麼就出現io submit 的文件描述符中間被關閉的狀況。

驗證

基於上面的分析，把上述 cache 容量上限調整到所在磁盤的文件數量的上限，進行了一樣的測試，長時間運行仍然穩定。所以，能夠認爲根因就是提交請求的文件描述符被fd cache中途關掉了。

總結

經過分析上面的問題能夠看到，針對通常的錯誤，咱們首先須要知道直接緣由，好比io submit 錯誤，須要知道錯誤碼的含義、可能致使的緣由；而後據此結合時間系統上下文進行分析排查，才能完全定位、解決問題。