2005 年 4 月 本文闡述 Linux 中的文件系統部分，源代碼來(lái)自基于 IA32 的 2.4.20 內核?？傮w上說(shuō) Linux 下的文件系統主要可分為三大塊：一是上層的文件系統的系統調用，二是虛擬文件系統 VFS(Virtual Filesystem Switch)，三是掛載到 VFS 中的各實(shí)際文件系統，例如 ext2，jffs 等。本文側重于通過(guò)具體的代碼分析來(lái)解釋 Linux 內核中 VFS 的內在機制，在這過(guò)程中會(huì )涉及到上層文件系統調用和下層實(shí)際文件系統的如何掛載。文章試圖從一個(gè)比較高的角度來(lái)解釋 Linux 下的 VFS 文件系統機制。 1. 摘要 相對來(lái)說(shuō)，VFS 部分的代碼比較繁瑣復雜，希望讀者在閱讀完本文之后，能對 Linux 下的 VFS 整體運作機制有個(gè)清楚的理解。建議讀者在閱讀本文前，先嘗試著(zhù)自己閱讀一下文件系統的源代碼，以便建立起 Linux 下文件系統最基本的概念，比如至少應熟悉 super block, dentry, inode，vfsmount 等數據結構所表示的意義，這樣再來(lái)閱讀本文以便加深理解。 2. VFS 概述  3. 文件系統的注冊 3.1 數據結構
注冊過(guò)程實(shí)際上將表示各實(shí)際文件系統的 struct file_system_type 數據結構的實(shí)例化，然后形成一個(gè)鏈表，內核中用一個(gè)名為 file_systems 的全局變量來(lái)指向該鏈表的表頭。 3.2 注冊 rootfs 文件系統 init_rootfs() 通過(guò)調用 register_filesystem(&rootfs_fs_type) 函數來(lái)完成 rootfs 文件系統注冊的，其中rootfs_fs_type 定義如下：
注冊之后的 file_systems 鏈表結構如下圖2所示：  4. VFS 目錄樹(shù)的建立 首先，init_mount_tree() 函數會(huì )調用 do_kern_mount("rootfs", 0, "rootfs", NULL) 來(lái)掛載前面已經(jīng)注冊了的 rootfs 文件系統。這看起來(lái)似乎有點(diǎn)奇怪，因為根據前面的說(shuō)法，似乎是應該先有掛載目錄，然后再在其上掛載相應的文件系統，然而此時(shí) VFS 似乎并沒(méi)有建立其根目錄。沒(méi)關(guān)系，這是因為這里我們調用的是 do_kern_mount()，這個(gè)函數內部自然會(huì )創(chuàng )建我們最關(guān)心也是最關(guān)鍵的根目錄(在 Linux 中，目錄對應的數據結構是 struct dentry)。 在這個(gè)場(chǎng)景里，do_kern_mount() 做的工作主要是： 1）調用 alloc_vfsmnt() 函數在內存里申請了一塊該類(lèi)型的內存空間（struct vfsmount *mnt），并初始化其部分成員變量。 2) 調用 get_sb_nodev（） 函數在內存中分配一個(gè)超級塊結構 (struct super_block) sb，并初始化其部分成員變量，將成員 s_instances 插入到 rootfs 文件系統類(lèi)型結構中的 fs_supers 指向的雙向鏈表中。 3) 通過(guò) rootfs 文件系統中的 read_super 函數指針調用 ramfs_read_super() 函數。還記得當初注冊rootfs 文件系統時(shí)，其成員 read_super 指針指向了 ramfs_read_super() 函數，參見(jiàn)圖2. 4) ramfs_read_super() 函數調用 ramfs_get_inode() 在內存中分配了一個(gè) inode 結構 (struct inode) inode，并初始化其部分成員變量，其中比較重要的有 i_op、i_fop 和 i_sb：
這使得將來(lái)通過(guò)文件系統調用對 VFS 發(fā)起的文件操作等指令將被 rootfs 文件系統中相應的函數接口所接管。  5) ramfs_read_super() 函數在分配和初始化了 inode 結構之后，會(huì )調用 d_alloc_root() 函數來(lái)為 VFS的目錄樹(shù)建立起關(guān)鍵的根目錄 (struct dentry)dentry，并將 dentry 中的 d_sb 指針指向 sb，d_inode 指針指向 inode。 6) 將 mnt 中的 mnt_sb 指針指向 sb，mnt_root 和 mnt_mountpoint 指針指向 dentry，而 mnt_parent指針則指向自身。 這樣，當 do_kern_mount() 函數返回時(shí)，以上分配出來(lái)的各數據結構和 rootfs 文件系統的關(guān)系將如上圖 3 所示。圖中 mnt、sb、inode、dentry 結構塊下方的數字表示它們在內存里被分配的先后順序。限于篇幅的原因，各結構中只給出了部分成員變量，讀者可以對照源代碼根據圖中所示按圖索驥，以加深理解。 最后，init_mount_tree() 函數會(huì )為系統最開(kāi)始的進(jìn)程(即 init_task 進(jìn)程)準備它的進(jìn)程數據塊中的namespace 域，主要目的是將 do_kern_mount() 函數中建立的 mnt 和 dentry 信息記錄在了 init_task 進(jìn)程的進(jìn)程數據塊中，這樣所有以后從 init_task 進(jìn)程 fork 出來(lái)的進(jìn)程也都先天地繼承了這一信息，在后面用sys_mkdir 在 VFS 中創(chuàng )建一個(gè)目錄的過(guò)程中，我們可以看到這里為什么要這樣做。為進(jìn)程建立 namespace 的主要代碼如下：
該段代碼的最后兩行便是將 do_kern_mount() 函數中建立的 mnt 和 dentry 信息記錄在了當前進(jìn)程的 fs結構中。 以上講了一大堆數據結構的來(lái)歷，其實(shí)最終目的不過(guò)是要在內存中建立一顆 VFS 目錄樹(shù)而已，更確切地說(shuō)， init_mount_tree() 這個(gè)函數為 VFS 建立了根目錄 "/"，而一旦有了根，那么這棵數就可以發(fā)展壯大，比如可以通過(guò)系統調用 sys_mkdir 在這棵樹(shù)上建立新的葉子節點(diǎn)等，所以系統設計者又將 rootfs 文件系統掛載到了這棵樹(shù)的根目錄上。關(guān)于 rootfs 這個(gè)文件系統，讀者如果看一下前面圖 2 中它的file_system_type 結構，會(huì )發(fā)現它的一個(gè)成員函數指針 read_super 指向的是 ramfs_read_super，單從這個(gè)函數名稱(chēng)中的 ramfs，讀者大概能猜測出這個(gè)文件所涉及的文件操作都是針對內存中的數據對象，事實(shí)上也的確如此。從另一個(gè)角度而言，因為 VFS 本身就是內存中的一個(gè)數據對象，所以在其上的操作僅限于內存，那也是非常合乎邏輯的事。在接下來(lái)的章節中，我們會(huì )用一個(gè)具體的例子來(lái)討論如何利用 rootfs所提供的函樹(shù)為 VFS 增加一個(gè)新的目錄節點(diǎn)。 VFS 中各目錄的主要用途是為以后掛載文件系統提供掛載點(diǎn)。所以真正的文件操作還是要通過(guò)掛載后的文件系統提供的功能接口來(lái)進(jìn)行。 5. VFS 下目錄的建立 要在 VFS 中建立一個(gè)新的目錄，首先我們得對該目錄進(jìn)行搜索，搜索的目的是找到將要建立的目錄其父目錄的相關(guān)信息，因為"皮之不存，毛將焉附"。比如要建立目錄 /home/ricard，那么首先必須沿目錄路徑進(jìn)行逐層搜索，本例中先從根目錄找起，然后在根目錄下找到目錄 home，然后再往下，便是要新建的目錄名 ricard，那么前面講得要先對目錄搜索，在該例中便是要找到 ricard 這個(gè)新目錄的父目錄，也就是 home 目錄所對應的信息。 當然，如果搜索的過(guò)程中發(fā)現錯誤，比如要建目錄的父目錄并不存在，或者當前進(jìn)程并無(wú)相應的權限等等，這種情況系統必然會(huì )調用相關(guān)過(guò)程進(jìn)行處理，對于此種情況，本文略過(guò)不提。 Linux 下用系統調用 sys_mkdir 來(lái)在 VFS 目錄樹(shù)中增加新的節點(diǎn)。同時(shí)為配合路徑搜索，引入了下面一個(gè)數據結構：
這個(gè)數據結構在路徑搜索的過(guò)程中用來(lái)記錄相關(guān)信息，起著(zhù)類(lèi)似"路標"的作用。其中前兩項中的 dentry記錄的是要建目錄的父目錄的信息，mnt 成員接下來(lái)會(huì )解釋到。后三項記錄的是所查找路徑的最后一個(gè)節點(diǎn)(即待建目錄或文件)的信息。 現在為建立目錄 "/dev" 而調用 sys_mkdir("/dev", 0700)，其中參數 0700 我們不去管它，它只是限定將要建立的目錄的某種模式。sys_mkdir 函數首先調用 path_lookup("/dev", LOOKUP_PARENT, &nd)；來(lái)對路徑進(jìn)行查找，其中 nd 為 struct nameidata nd 聲明的變量。在接下來(lái)的敘述中，因為函數調用關(guān)系的繁瑣，為了突出過(guò)程主線(xiàn)，將不再?lài)栏癜凑蘸瘮档恼{用關(guān)系來(lái)進(jìn)行描述。 path_lookup 發(fā)現 "/dev" 是以 "/" 開(kāi)頭，所以它從當前進(jìn)程的根目錄開(kāi)始往下查找，具體代碼如下：
記得在 init_mount_tree() 函數的后半段曾經(jīng)將新建立的 VFS 根目錄相關(guān)信息記錄在了 init_task 進(jìn)程的進(jìn)程數據塊中，那么在這個(gè)場(chǎng)景里，nd->mnt 便指向了圖 3 中 mnt 變量，nd->dentry 便指向了圖 3 中的 dentry 變量。 然后調用函數 path_walk 接著(zhù)往下查找，找到最后通過(guò)變量 nd 返回的信息是 nd.last.name="dev"，nd.last.len=3，nd.last_type=LAST_NORM，至于 nd 中 mnt 和 dentry 成員，在這個(gè)場(chǎng)景里還是前面設置的值，并無(wú)變化。這樣一圈下來(lái)，只是用 nd 記錄下相關(guān)信息，實(shí)際的目錄建立工作并沒(méi)有真正展開(kāi)，但是前面所做的工作卻為接下來(lái)建立新的節點(diǎn)收集了必要的信息。 好，到此為止真正建立新目錄節點(diǎn)的工作將會(huì )展開(kāi)，這是由函數 lookup_create 來(lái)完成的，調用這個(gè)函數時(shí)會(huì )傳入兩個(gè)參數：lookup_create(&nd, 1)；其中參數 nd 便是前面提到的變量，參數1表明要建立一個(gè)新目錄。 這里的大體過(guò)程是：新分配了一個(gè) struct dentry 結構的內存空間，用于記錄 dev 目錄所對應的信息，該dentry 結構將會(huì )掛接到其父目錄中，也就是圖 3 中 "/" 目錄對應的 dentry 結構中，由鏈表實(shí)現這一關(guān)系。接下來(lái)會(huì )再分配一個(gè) struct inode 結構。Inode 中的 i_sb 和 dentry 中的 d_sb 分別都指向圖 3 中的 sb，這樣看來(lái)，在同一文件系統下建立新的目錄時(shí)并不需要重新分配一個(gè)超級塊結構，因為畢竟它們都屬于同一文件系統，因此一個(gè)文件系統只對應一個(gè)超級塊。 這樣，當調用 sys_mkdir 成功地在 VFS 的目錄樹(shù)中新建立一個(gè)目錄 "/dev" 之后，在圖 3 的基礎上，新的數據結構之間的關(guān)系便如圖 4 所示。圖 4 中顏色較深的兩個(gè)矩形塊 new_inode 和 new_entry 便是在sys_mkdir() 函數中新分配的內存結構，至于圖中的 mnt,sb,dentry,inode 等結構，仍為圖 3 中相應的數據結構，其相互之間的鏈接關(guān)系不變(圖中為避免過(guò)多的鏈接曲線(xiàn)，忽略了一些鏈接關(guān)系，如 mnt 和 sb,dentry之間的鏈接，讀者可在圖 3 的基礎上參看圖 4)。 需要強調一點(diǎn)的是，既然 rootfs 文件系統被 mount 到了 VFS 樹(shù)上，那么它在 sys_mkdir 的過(guò)程中必然會(huì )參與進(jìn)來(lái)，事實(shí)上在整個(gè)過(guò)程中，rootfs 文件系統中的 ramfs_mkdir、ramfs_lookup 等函數都曾被調用過(guò)。  6. 在 VFS 樹(shù)中掛載文件系統 這一過(guò)程可簡(jiǎn)單描述為：將某一設備(dev_name)上某一文件系統(file_system_type)安裝到VFS目錄樹(shù)上的某一安裝點(diǎn)(dir_name)。它要解決的問(wèn)題是：將對 VFS 目錄樹(shù)中某一目錄的操作轉化為具體安裝到其上的實(shí)際文件系統的對應操作。比如說(shuō)，如果將 hda2 上的根文件系統(假設文件系統類(lèi)型為 ext2)安裝到了前一節中新建立的 "/dev" 目錄上(此時(shí)，"/dev" 目錄就成為了安裝點(diǎn))，那么安裝成功之后應達到這樣的目的，即：對 VFS 文件系統的 "/dev" 目錄執行 "ls" 指令，該條指令應能列出 hda2 上 ext2 文件系統的根目錄下所有的目錄和文件。很顯然，這里的關(guān)鍵是如何將對 VFS 樹(shù)中 "/dev" 的目錄操作指令轉化為安裝在其上的 ext2 這一實(shí)際文件系統中的相應指令。所以，接下來(lái)的敘述將抓住如何轉化這一核心問(wèn)題。在敘述之前，讀者不妨自己設想一下 Linux 系統會(huì )如何解決這一問(wèn)題。記?。簩δ夸浕蛭募牟僮鲗⒆罱K由目錄或文件所對應的 inode 結構中的 i_op 和 i_fop 所指向的函數表中對應的函數來(lái)執行。所以，不管最終解決方案如何，都可以設想必然要通過(guò)將對 "/dev" 目錄所對應的 inode 中 i_op 和 i_fop 的調用轉換到 hda2 上根文件系統 ext2 中根目錄所對應的 inode 中 i_op 和 i_fop 的操作。 初始過(guò)程由 sys_mount() 系統調用函數發(fā)起，該函數原型聲明如下：
其中，參數 char *type 為標識將要安裝的文件系統類(lèi)型字符串，對于 ext2 文件系統而言，就是"ext2"。參數 flags 為安裝時(shí)的模式標識數，和接下來(lái)的 data 參數一樣，本文不將其做為重點(diǎn)。 為了幫助讀者更好地理解這一過(guò)程，筆者用一個(gè)具體的例子來(lái)說(shuō)明：我們準備將來(lái)自主硬盤(pán)第 2 分區(hda2)上的 ext2 文件系統安裝到前面創(chuàng )建的 "/dev" 目錄中。那么對于 sys_mount() 函數的調用便具體為：
該函數在將這些來(lái)自用戶(hù)內存空間(user space)的參數拷貝到內核空間后，便調用 do_mount() 函數開(kāi)始真正的安裝文件系統的工作。同樣，為了便于敘述和講清楚主流程，接下來(lái)的說(shuō)明將不嚴格按照具體的函數調用細節來(lái)進(jìn)行。 do_mount() 函數會(huì )首先調用 path_lookup() 函數來(lái)得到安裝點(diǎn)的相關(guān)信息，如同創(chuàng )建目錄過(guò)程中敘述的那樣，該安裝點(diǎn)的信息最終記錄在 struct nameidata 類(lèi)型的一個(gè)變量當中，為敘述方便，記該變量為nd。在本例中當 path_lookup() 函數返回時(shí)，nd 中記錄的信息如下：nd.entry = new_entry; nd.mnt = mnt; 這里的變量如圖 3 和 4 中所示。 然后，do_mount() 函數會(huì )根據調用參數 flags 來(lái)決定調用以下四個(gè)函數之一：do_remount()、 do_loopback()、do_move_mount()、do_add_mount()。 在我們當前的例子中，系統會(huì )調用 do_add_mount() 函數來(lái)向 VFS 樹(shù)中安裝點(diǎn) "/dev " 安裝一個(gè)實(shí)際的文件系統。在 do_add_mount() 中，主要完成了兩件重要事情：一是獲得一個(gè)新的安裝區域塊，二是將該新的安裝區域塊加入了安裝系統鏈表。它們分別是調用 do_kern_mount() 函數和 graft_tree() 函數來(lái)完成的。這里的描述可能有點(diǎn)抽象，諸如安裝區域塊、安裝系統鏈表等，不過(guò)不用著(zhù)急，因為它們都是筆者自己定義出來(lái)的概念，等一下到后面會(huì )有專(zhuān)門(mén)的圖表解釋?zhuān)綍r(shí)便會(huì )清楚。 do_kern_mount() 函數要做的事情，便是建立一新的安裝區域塊，具體的內容在前面的章節 VFS 目錄樹(shù)的建立中已經(jīng)敘述過(guò)，這里不再贅述。 graft_tree() 函數要做的事情便是將 do_kern_mount() 函數返回的一 struct vfsmount 類(lèi)型的變量加入到安裝系統鏈表中，同時(shí) graft_tree() 還要將新分配的 struct vfsmount 類(lèi)型的變量加入到一個(gè)hash表中，其目的我們將會(huì )在以后看到。 這樣，當 do_kern_mount() 函數返回時(shí)，在圖 4 的基礎上，新的數據結構間的關(guān)系將如圖 5 所示。其中，紅圈區域里面的數據結構便是被稱(chēng)做安裝區域塊的東西，其中不妨稱(chēng) e2_mnt 為安裝區域塊的指針，藍色箭頭曲線(xiàn)即構成了所謂的安裝系統鏈表。 在把這些函數調用后形成的數據結構關(guān)系理清楚之后，讓我們回到本章節開(kāi)始提到的問(wèn)題，即將 ext2 文件系統安裝到了 "/dev " 上之后，對該目錄上的操作如何轉化為對 ext2 文件系統相應的操作。從圖 5上看到，對 sys_mount() 函數的調用并沒(méi)有直接改變 "/dev " 目錄所對應的 inode (即圖中的 new_inode變量)結構中的 i_op 和 i_fop 指針，而且 "/dev " 所對應的 dentry(即圖中的 new_dentry 變量)結構仍然在 VFS 的目錄樹(shù)中，并沒(méi)有被從其中隱藏起來(lái)，相應地，來(lái)自 hda2 上的 ext2 文件系統的根目錄所對應的 e2_entry 也不是如當初筆者所想象地那樣將 VFS 目錄樹(shù)中的 new_dentry 取而代之，那么這之間的轉化到底是如何實(shí)現的呢？ 請讀者注意下面的這段代碼：
這段代碼在 link_path_walk() 函數中被調用，而 link_path_walk() 最終又會(huì )被 path_lookup() 函數調用，如果讀者閱讀過(guò) Linux 關(guān)于文件系統部分的代碼，應該知道 path_lookup() 函數在整個(gè) Linux 繁瑣的文件系統代碼中屬于一個(gè)重要的基礎性的函數。簡(jiǎn)單說(shuō)來(lái)，這個(gè)函數用于解析文件路徑名，這里的文件路徑名和我們平時(shí)在應用程序中所涉及到的概念相同，比如在 Linux 的應用程序中 open 或 read 一個(gè)文件 /home/windfly.cs 時(shí)，這里的 /home/windfly.cs 就是文件路徑名，path_lookup() 函數的責任就是對文件路徑名中進(jìn)行搜索，直到找到目標文件所屬目錄所對應的 dentry 或者目標直接就是一個(gè)目錄，筆者不想在有限的篇幅里詳細解釋這個(gè)函數，讀者只要記住 path_lookup() 會(huì )返回一個(gè)目標目錄即可。 上面的代碼非常地不起眼，以至于初次閱讀文件系統的代碼時(shí)經(jīng)常會(huì )忽略掉它，但是前文所提到從 VFS 的操作到實(shí)際文件系統操作的轉化卻是由它完成的，對 VFS 中實(shí)現的文件系統的安裝可謂功不可沒(méi)?，F在讓我們仔細剖析一下該段代碼： d_mountpoint(dentry) 的作用很簡(jiǎn)單，它只是返回 dentry 中 d_mounted 成員變量的值。這里的dentry 仍然還是 VFS 目錄樹(shù)上的東西。如果 VFS 目錄樹(shù)上某個(gè)目錄被安裝過(guò)一次，那么該值為 1。對VFS 中的一個(gè)目錄可進(jìn)行多次安裝，后面會(huì )有例子說(shuō)明這種情況。在我們的例子中，"/dev" 所對應的new_dentry 中 d_mounted=1，所以 while 循環(huán)中第一個(gè)條件滿(mǎn)足。下面再來(lái)看__follow_down(&nd->mnt, &dentry)代 圖 5：安裝 ext2 類(lèi)型根文件系統到 "/dev " 目錄上  碼做了什么？到此我們應該記住，這里 nd 中的 dentry 成員就是圖 5 中的 new_dentry，nd 中的 mnt成員就是圖 5 中的 mnt，所以我們現在可以把 __follow_down(&nd->mnt, &dentry) 改寫(xiě)成__follow_down(&mnt, &new_dentry)，接下來(lái)我們將 __follow_down() 函數的代碼改寫(xiě)(只是去處掉一些不太相關(guān)的代碼，并且為了便于說(shuō)明，在部分代碼行前加上了序號)如下：
代碼行[1]中的 lookup_mnt() 函數用于查找一個(gè) VFS 目錄樹(shù)下某一目錄最近一次被 mount 時(shí)的安裝區域塊的指針，在本例中最終會(huì )返回圖 5 中的 e2_mnt。至于查找的原理，這里粗略地描述一下。記得當我們在安裝 ext2 文件系統到 "/dev" 時(shí)，在后期會(huì )調用 graft_tree() 函數，在這個(gè)函數里會(huì )把圖 5 中的安裝區域塊指針 e2_mnt 掛到一 hash 表(Linux 2.4.20源代碼中稱(chēng)之為 mount_hashtable)中的某一項，而該項的鍵值就是由被安裝點(diǎn)所對應的 dentry(本例中為 new_dentry)和 mount(本例中為 mnt)所共同產(chǎn)生，所以自然地，當我們知道 VFS 樹(shù)中某一 dentry 被安裝過(guò)(該 dentry 變成為一安裝點(diǎn))，而要去查找其最近一次被安裝的安裝區域塊指針時(shí)，同樣由該安裝點(diǎn)所對應的 dentry 和 mount 來(lái)產(chǎn)生一鍵值，以此值去索引 mount_hashtable，自然可找到該安裝點(diǎn)對應的安裝區域塊指針形成的鏈表的頭指針，然后遍歷該鏈表，當發(fā)現某一安裝區域塊指針，記為 p，滿(mǎn)足以下條件時(shí)：
P 便為該安裝點(diǎn)所對應的安裝區域塊指針。當找到該指針后，便將 nd 中的 mnt 成員換成該安裝區域塊指針，同時(shí)將 nd 中的 dentry 成員換成安裝區域塊中的 dentry 指針。在我們的例子中，e2_mnt->mnt_root成員指向 e2_dentry，也就是 ext2 文件系統的 "/" 目錄。這樣，當 path_lookup() 函數搜索到 "/dev"時(shí)，nd 中的 dentry 成員為 e2_dentry，而不再是原來(lái)的 new_dentry，同時(shí) mnt 成員被換成 e2_mnt，轉化便在不知不覺(jué)中完成了。 現在考慮一下對某一安裝點(diǎn)多次安裝的情況，同樣作為例子，我們假設在 "/dev" 上安裝完一個(gè) ext2文件系統后，再在其上安裝一個(gè) ntfs 文件系統。在安裝之前，同樣會(huì )對安裝點(diǎn)所在的路徑調用path_lookup() 函數進(jìn)行搜索，但是這次由于在 "/dev" 目錄上已經(jīng)安裝過(guò)了 ext2 文件系統，所以搜索到最后，由 nd 返回的信息是：nd.dentry = e2_dentry, nd.mnt = e2_mnt。由此可見(jiàn)，在第二次安裝時(shí)，安裝點(diǎn)已經(jīng)由 dentry 變成了 e2_dentry。接下來(lái)，同樣地，系統會(huì )再分配一個(gè)安裝區域塊，假設該安裝區域塊的指針為 ntfs_mnt，區域塊中的 dentry 為 ntfs_dentry。ntfs_mnt 的父指針指向了e2_mnt，mnfs_mnt 中的 mnt_root 指向了代表 ntfs 文件系統根目錄的 ntfs_dentry。然后，系統通過(guò) e2_dentry和 e2_mnt 來(lái)生成一個(gè)新的 hash 鍵值，利用該值作為索引，將 ntfs_mnt 加入到 mount_hashtable 中，同時(shí)將 e2_dentry 中的成員 d_mounted 值設定為 1。這樣，安裝過(guò)程便告結束。 讀者可能已經(jīng)知道，對同一安裝點(diǎn)上的最近一次安裝會(huì )隱藏起前面的若干次安裝，下面我們通過(guò)上述的例子解釋一下該過(guò)程： 在先后將 ext2 和 ntfs 文件系統安裝到 "/dev" 目錄之后，我們再調用 path_lookup() 函數來(lái)對"/dev" 進(jìn)行搜索，函數首先找到 VFS 目錄樹(shù)下的安裝點(diǎn) "/dev" 所對應的 dentry 和 mnt，此時(shí)它發(fā)現dentry 成員中的 d_mounted 為 1，于是它知道已經(jīng)有文件系統安裝到了該 dentry 上，于是它通過(guò) dentry 和 mnt 來(lái)生成一個(gè) hash 值，通過(guò)該值來(lái)對 mount_hashtable 進(jìn)行搜索，根據安裝過(guò)程，它應該能找到 e2_mnt 指針并返回之，同時(shí)原先的 dentry 也已經(jīng)被替換成 e2_dentry?；仡^再看一下前面已經(jīng)提到的下列代碼： while (d_mountpoint(dentry) && __follow_down(&nd->mnt, &dentry)); 當第一次循環(huán)結束后, nd->mnt 已經(jīng)是 e2_mnt，而 dentry 則變成 e2_dentry。此時(shí)由于 e2_dentry 中的成員 d_mounted 值為 1，所以 while 循環(huán)的第一個(gè)條件滿(mǎn)足，要繼續調用 __follow_down() 函數，這個(gè)函數前面已經(jīng)剖析過(guò)，當它返回后 nd->mnt 變成了 ntfs_mnt，dentry 則變成了 ntfs_dentry。由于此時(shí) ntfs_dentry 沒(méi)有被安裝過(guò)其他文件，所以它的成員 d_mounted 應該為 0，循環(huán)結束。對 "/dev" 發(fā)起的 path_lookup() 函數最終返回了 ntfs 文件系統根目錄所對應的 dentry。這就是為什么 "/dev" 本身和安裝在其上的 ext2 都被隱藏的原因。如果此時(shí)對 "/dev" 目錄進(jìn)行一個(gè) ls 命令，將返回安裝上去的 ntfs 文件系統根目錄下所有的文件和目錄。 7. 安裝根文件系統 這個(gè)過(guò)程大致是：首先要確定待安裝的 ext2 文件系統的來(lái)源，其次是確定 ext2 文件系統在 VFS中的安裝點(diǎn)，然后便是具體的安裝過(guò)程。 關(guān)于第一問(wèn)題，Linux 2.4.20 的內核另有一大堆的代碼去解決，限于篇幅，筆者不想在這里去具體說(shuō)明這個(gè)過(guò)程，大概記住它是要解決到哪里去找要安裝的文件系統的就可以了，這里我們不妨就認為要安裝的根文件系統就來(lái)自于主硬盤(pán)的第一分區 hda1. 關(guān)于第二個(gè)問(wèn)題，Linux 2.4.20 的內核把來(lái)自于 hda1 上 ext2 文件系統安裝到了 VFS 目錄樹(shù)中的"/root" 目錄上。其實(shí)，把 ext2 文件系統安裝到 VFS 目錄樹(shù)下的哪個(gè)安裝點(diǎn)并不重要(VFS 的根目錄除外)，只要是這個(gè)安裝點(diǎn)在 VFS 樹(shù)中是存在的，并且內核對它沒(méi)有另外的用途。如果讀者喜歡，盡可以自己在 VFS 中創(chuàng )建一個(gè) "/Windows" 目錄，然后將 ext2 文件系統安裝上去作為將來(lái)用戶(hù)進(jìn)程的根目錄，沒(méi)有什么不可以的。問(wèn)題的關(guān)鍵是要將進(jìn)程的根目錄和當前工作目錄設定好，因為畢竟只用用戶(hù)進(jìn)程才去關(guān)心現實(shí)的文件系統，要知道筆者的這篇稿子可是要存到硬盤(pán)上去的。 在 Linux 下，設定一個(gè)進(jìn)程的當前工作目錄是通過(guò)系統調用 sys_chdir() 進(jìn)行的。初始化期間，Linux 在將 hda1 上的 ext2 文件系統安裝到了 "/root" 上后，通過(guò)調用 sys_chdir("/root") 將當前進(jìn)程，也就是 init_task 進(jìn)程的當前工作目錄(pwd)設定為 ext2 文件系統的根目錄。記住此時(shí) init_task進(jìn)程的根目錄仍然是圖 3 中的 dentry，也就是 VFS 樹(shù)的根目錄，這顯然是不行的，因為以后 Linux 世界中的所有進(jìn)程都由這個(gè) init_task 進(jìn)程派生出來(lái)，無(wú)一例外地要繼承該進(jìn)程的根目錄，如果是這樣，意味著(zhù)用戶(hù)進(jìn)程從根目錄搜索某一目錄時(shí)，實(shí)際上是從 VFS 的根目錄開(kāi)始的，而事實(shí)上卻是從 ext2 的根文件開(kāi)始搜索的。這個(gè)矛盾的解決是靠了在調用完 mount_root() 函數后，系統調用的下面兩個(gè)函數：
其主要作用便是將 init_task 進(jìn)程的根目錄轉化成安裝上去的 ext2 文件系統的根目錄。有興趣的讀者可以自行去研究這一過(guò)程。 所以在用戶(hù)空間下，更多地情況是只能見(jiàn)到 VFS 這棵大樹(shù)的一葉，而且還是被安裝過(guò)文件系統了的，實(shí)際上對用戶(hù)空間來(lái)說(shuō)還是不可見(jiàn)。我想，VFS 更多地被內核用來(lái)實(shí)現自己的功能，并以系統調用的方式提供過(guò)用戶(hù)進(jìn)程使用，至于在其上實(shí)現的不同文件系統的安裝，也只是其中的一個(gè)功能罷了。 8. 結束語(yǔ) |
聯(lián)系客服
