現象
在本人的系統軟件中調用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 錯誤，需要知道錯誤碼的含義、可能導致的原因；然後據此結合時間系統上下文進行分析排查，才能徹底定位、解決問題。