以nfs4 direct_read過程為例，過程中的幾個控制結構
dreq，每個io過程的上下文，記錄所有io的引數，及中間產生的狀態值
nfs_pageio_descriptor， 核心中操作記憶體都是以page為單位，記憶體buf最終會轉換為多個page組成的list，該型別中，包含list指標，由於dio請求的長度是由系統呼叫者指定的，所以不可能一次性將資料全部傳送，會按照指定的bsize（掛載時指定的每次io大小進行分拆），每次拆分之後呼叫一次該描述符的pg_doio（nfs_generic_pg_readpages）介面，這個pg_doio過程也只是再次進行分拆，不會阻塞呼叫。doio之後，會再次設定nfs_pageio_descriptor的page_count和pg_list，直到將整個dreq中的buff都處理完
nfs_read_header和nfs_pgio_header
nfs_read_header包含了nfs_pgio_header的結構，幷包括nfs_read_data結構，每次呼叫pg_doio就會生成乙個nfs_pgio_header結構，乙個nfs_pgio_header初始包括descpg_list中的第乙個req，如果指定的bsize（傳輸大小的限制）
nfs_read_data，如果乙個bsize小於乙個page的大小，那麼需要再次進行拆分，拆分成多個nfs_read_data結構，否則只建立乙個nfs_read_data結構，最終使用每個nfs_read_data構建乙個rpc_task
call_start
call_reserve->xprt_reserve
call_reserveresult
call_refresh->rpcauth_refreshcred
call_refreshresult
call_allocate->xprt->ops->buf_alloc 此處只是申請緩衝區用來存放訊息的控制結構，資料部分是使用page指標
call_bind->xprt->ops->rpcbind(task) 此處有標記為檢查，已經bound，直接跳過
call_connect->xprt_connect 此處也有標記檢查，已經連線直接跳過
call_connect_status 如果執行了xprt_connect操作，那麼下一步需要檢查連線狀態，已經建立連線跳過該步
call_transmit->xprt_prepare_transmit->xprt->ops->reserve_xprt 此處會設定xprt的鎖標記->rpc_xdr_encode->xprt_transmit->xprt->ops->send_request ，此處可能會因為傳送緩衝區滿而無法繼續傳送，但是會記錄已經傳送的長度，不會全部從頭開始->rpc_sleep_on 在call_transimit，將task在等待佇列上，此處不是立即掛起，而是在call_transmi調結束之後，不在呼叫其他action->call_transmit_status->xprt_end_transmit->xprt_release_write ，此處會釋放xprt
call_transmit_status 如果在執行call_transmit過程中出現錯誤，則task不會掛起，而是執行該步驟
call_status
call_decode
未完待續
hadoop 原始碼筆記
public inte ce tool extends configurable public int run string args throws exception public static void main string args throws exception toolrunner執行...
linux softirq 原始碼 筆記
asmlinkage void do softirq void asmlinkage void do softirq void h pending 1 while pending local irq disable pending local softirq pending if pending m...
URLClassLoader原始碼筆記
在搜尋載入jar檔案時，滿屏都是urlclassloader，簡直是被玩壞了。作為不求甚解的人，都覺得太過不去了，看看原始碼吧。urlclassloader的最終基類是classloader。urlclassloader的直接父類是secureclassloader，僅僅是做了乙個protectio...