Linux程式設計學習筆記----檔案管理系統

Linux程式設計學習筆記----檔案管理系統

本文部分整理自網路

Linux下檔案系統管理1.VFS檔案系統概述

linux採用VFS來管理檔案系統，而且linux設計的原則之一就是everything is file。因此檔案管理系統是linux設計最核心的體現。

VFS的全稱是Virtual File System （虛擬檔案系統）。

總體上說 Linux 下的檔案系統主要可分為三大塊：一是上層的檔案系統的系統調用，二是虛擬檔案系統 VFS(Virtual Filesystem Switch)，三是掛載到 VFS 中的各實際檔案系統，例如 ext2，jffs 等。

VFS 是一種軟體機制，也許稱它為 Linux 的檔案系統管理者更確切點，與它相關的資料結構只存在於實體記憶體當中。所以在每次系統初始化期間，Linux 都首先要在記憶體當中構造一棵 VFS 的分類樹(在 Linux 的原始碼裡稱之為 namespace)，實際上便是在記憶體中建立相應的資料結構。VFS 分類樹在 Linux 的檔案系統模組中是個很重要的概念，希望讀者不要將其與實際檔案系統分類樹混淆，在筆者看來，VFS 中的各目錄其主要用途是用來提供實際檔案系統的掛載點，當然在 VFS 中也會涉及到檔案級的操作，本文不闡述這種情況。下文提到分類樹或目錄，如果不特別說明，均指 VFS 的分類樹或目錄。圖是一種可能的分類樹在記憶體中的影像：

2.檔案系統的註冊

這裡的檔案系統是指可能會被掛載到分類樹中的各個實際檔案系統，所謂實際檔案系統，即是指VFS 中的實際操作最終要通過它們來完成而已，並不意味著它們一定要存在於某種特定的存放裝置上。比如在有的 Linux 機器下就註冊有 "rootfs"、"proc"、"ext2"、"sockfs" 等十幾種檔案系統。

2.1 資料結構

在 Linux 原始碼中，每種實際的檔案系統用以下的資料結構表示：

struct file_system_type {const char *name;int fs_flags;struct super_block *(*read_super) (struct super_block *, void *, int);struct module *owner;struct file_system_type * next;struct list_head fs_supers;};

註冊過程實際上將表示各實際檔案系統的 struct file_system_type 資料結構的執行個體化，然後形成一個鏈表，核心中用一個名為 file_systems 的全域變數來指向該鏈表的表頭。2.2 註冊 rootfs 檔案系統

在眾多的實際檔案系統中，之所以單獨介紹 rootfs 檔案系統的註冊過程，實在是因為該檔案系統 VFS 的關係太過密切，如果說 ext2/ext3 是 Linux 的本土檔案系統，那麼 rootfs 檔案系統則是 VFS 存在的基礎。一般檔案系統的註冊都是通過 module_init 宏以及 do_initcalls() 函數來完成(讀者可通過閱讀module_init 宏的聲明及 arch\i386\vmlinux.lds 檔案來理解這一過程)，但是 rootfs 的註冊卻是通過 init_rootfs() 這一初始化函數來完成，這意味著 rootfs 的註冊過程是 Linux 核心初始化階段不可分割的一部分。

init_rootfs() 通過調用 register_filesystem(&rootfs_fs_type) 函數來完成 rootfs 檔案系統註冊的，其中rootfs_fs_type 定義如下：

 struct file_system_type rootfs_fs_type = { \name:"rootfs", \read_super:ramfs_read_super, \fs_flags:FS_NOMOUNT|FS_LITTER, \owner:THIS_MODULE, \ }

註冊之後的 file_systems 鏈表結構如所示：

3.VFS 分類樹的建立

既然是樹，所以根是其賴以存在的基礎，本節闡述 Linux 在初始化階段是如何建立根結點的，即 "/"目錄。這其中會包括掛載 rootfs 檔案系統到根目錄 "/" 的具體過程。構造根目錄的代碼是在 init_mount_tree（） 函數 （fs\namespace.c） 中。

首先，init_mount_tree() 函數會調用 do_kern_mount("rootfs", 0, "rootfs", NULL) 來掛載前面已經註冊了的 rootfs 檔案系統。這看起來似乎有點奇怪，因為根據前面的說法，似乎是應該先有掛載目錄，然後再在其上掛載相應的檔案系統，然而此時 VFS 似乎並沒有建立其根目錄。沒關係，這是因為這裡我們調用的是 do_kern_mount()，這個函數內部自然會建立我們最關心也是最關鍵的根目錄(在 Linux 中，目錄對應的資料結構是 struct dentry)。

在這個情境裡，do_kern_mount() 做的工作主要是：

1）調用 alloc_vfsmnt() 函數在記憶體裡申請了一塊該類型的記憶體空間（struct vfsmount *mnt），並初始化其部分成員變數。

2) 調用 get_sb_nodev（） 函數在記憶體中分配一個超級塊結構 (struct super_block) sb，並初始化其部分成員變數，將成員 s_instances 插入到 rootfs 檔案系統類型結構中的 fs_supers 指向的雙向鏈表中。

3) 通過 rootfs 檔案系統中的 read_super 函數指標調用 ramfs_read_super() 函數。還記得當初註冊rootfs 檔案系統時，其成員 read_super 指標指向了 ramfs_read_super() 函數，參見.

4) ramfs_read_super() 函數調用 ramfs_get_inode() 在記憶體中分配了一個 inode 結構 (struct inode) inode，並初始化其部分成員變數，其中比較重要的有 i_op、i_fop 和 i_sb：

inode->i_op = &ramfs_dir_inode_operations;inode->i_fop = &dcache_dir_ops;inode->i_sb = sb;

這使得將來通過檔案系統調用對 VFS 發起的檔案操作等指令將被 rootfs 檔案系統中相應的函數介面所接管。

5) ramfs_read_super() 函數在分配和初始化了 inode 結構之後，會調用 d_alloc_root() 函數來為 VFS的分類樹建立起關鍵的根目錄 (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() 函數返回時，以上分配出來的各資料結構和 rootfs 檔案系統的關係將如所示。

圖中 mnt、sb、inode、dentry 結構塊下方的數字表示它們在記憶體裡被分配的先後順序。限於篇幅的原因，各結構中只給出了部分成員變數，讀者可以對照原始碼根據圖中所示按圖索驥，以加深理解。

最後，init_mount_tree() 函數會為系統最開始的進程(即 init_task 進程)準備它的進程資料區塊中的namespace 域，主要目的是將 do_kern_mount() 函數中建立的 mnt 和 dentry 資訊記錄在了 init_task 進程的進程資料區塊中，這樣所有以後從 init_task 進程 fork 出來的進程也都先天地繼承了這一資訊，在後面用sys_mkdir 在 VFS 中建立一個目錄的過程中，我們可以看到這裡為什麼要這樣做。為進程建立 namespace 的主要代碼如下：

namespace = kmalloc(sizeof(*namespace), GFP_KERNEL);   list_add(&mnt->mnt_list, &namespace->list);  //mnt is returned by do_kern_mount()namespace->root = mnt;init_task.namespace = namespace;for_each_task(p) {get_namespace(namespace);p->namespace = namespace;}set_fs_pwd(current->fs, namespace->root, namespace->root->mnt_root);set_fs_root(current->fs, namespace->root, namespace->root->mnt_root);

該段代碼的最後兩行便是將 do_kern_mount() 函數中建立的 mnt 和 dentry 資訊記錄在了當前進程的 fs結構中。

以上講了一大堆資料結構的來曆，其實最終目的不過是要在記憶體中建立一顆 VFS 分類樹而已，更確切地說， init_mount_tree() 這個函數為 VFS 建立了根目錄 "/"，而一旦有了根，那麼這棵數就可以發展壯大，比如可以通過系統調用 sys_mkdir 在這棵樹上建立新的葉子節點等，所以系統設計者又將 rootfs 檔案系統掛載到了這棵樹的根目錄上。關於 rootfs 這個檔案系統，讀者如果看一下前面圖 2 中它的file_system_type 結構，會發現它的一個成員函數指標 read_super 指向的是 ramfs_read_super，單從這個函數名稱中的 ramfs，讀者大概能猜測出這個檔案所涉及的檔案操作都是針對記憶體中的資料對象，事實上也的確如此。從另一個角度而言，因為 VFS 本身就是記憶體中的一個資料對象，所以在其上的操作僅限於記憶體，那也是非常合乎邏輯的事。在接下來的章節中，我們會用一個具體的例子來討論如何利用 rootfs所提供的函樹為 VFS 增加一個新的目錄節點。

VFS 中各目錄的主要用途是為以後掛載檔案系統提供掛載點。所以真正的檔案操作還是要通過掛載後的檔案系統提供的功能介面來進行。

4. VFS 下目錄的建立

為了更好地理解 VFS，下面我們用一個實際例子來看看 Linux 是如何在 VFS 的根目錄下建立一個新的目錄 "/dev" 的。

要在 VFS 中建立一個新的目錄，首先我們得對該目錄進行搜尋，搜尋的目的是找到將要建立的目錄其父目錄的相關資訊，因為"皮之不存，毛將焉附"。比如要建立目錄 /home/ricard，那麼首先必須沿目錄路徑進行逐層搜尋，本例中先從根目錄找起，然後在根目錄下找到目錄 home，然後再往下，便是要建立的目錄名 ricard，那麼前面講得要先對目錄搜尋，在該例中便是要找到 ricard 這個新目錄的父目錄，也就是 home 目錄所對應的資訊。

當然，如果搜尋的過程中發現錯誤，比如要建目錄的父目錄並不存在，或者當前進程並無相應的許可權等等，這種情況系統必然會調用相關過程進行處理，對於此種情況，本文略過不提。

Linux 下用系統調用 sys_mkdir 來在 VFS 分類樹中增加新的節點。同時為配合路徑搜尋，引入了下面一個資料結構：

struct nameidata {struct dentry *dentry;struct vfsmount *mnt;struct qstr last;unsigned int flags;int last_type;};

這個資料結構在路徑搜尋的過程中用來記錄相關資訊，起著類似"路標"的作用。其中前兩項中的 dentry記錄的是要建目錄的父目錄的資訊，mnt 成員接下來會解釋到。後三項記錄的是所尋找路徑的最後一個節點(即待建目錄或檔案)的資訊。 現在為建立目錄 "/dev" 而調用 sys_mkdir("/dev", 0700)，其中參數 0700 我們不去管它，它只是限定將要建立的目錄的某種模式。sys_mkdir 函數首先調用 path_lookup("/dev", LOOKUP_PARENT, &nd)；來對路徑進行尋找，其中 nd 為 struct nameidata nd 聲明的變數。在接下來的敘述中，因為函數調用關係的繁瑣，為了突出過程主線，將不再嚴格按照函數的調用關係來進行描述。

path_lookup 發現 "/dev" 是以 "/" 開頭，所以它從當前進程的根目錄開始往下尋找，具體代碼如下：

nd->mnt = mntget(current->fs->rootmnt);nd->dentry = dget(current->fs->root);

記得在 init_mount_tree() 函數的後半段曾經將建立立的 VFS 根目錄相關資訊記錄在了 init_task 進程的進程資料區塊中，那麼在這個情境裡，nd->mnt 便指向了圖 3 中 mnt 變數，nd->dentry 便指向了圖 3 中的 dentry 變數。

然後調用函數 path_walk 接著往下尋找，找到最後通過變數 nd 返回的資訊是 nd.last.name="dev"，nd.last.len=3，nd.last_type=LAST_NORM，至於 nd 中 mnt 和 dentry 成員，在這個情境裡還是前面設定的值，並無變化。這樣一圈下來，只是用 nd 記錄下相關資訊，實際的目錄建立工作並沒有真正展開，但是前面所做的工作卻為接下來建立新的節點收集了必要的資訊。

好，到此為止真正建立新目錄節點的工作將會展開，這是由函數 lookup_create 來完成的，調用這個函數時會傳入兩個參數：lookup_create(&nd, 1)；其中參數 nd 便是前面提到的變數，參數1表明要建立一個新目錄。

這裡的大體過程是：新分配了一個 struct dentry 結構的記憶體空間，用於記錄 dev 目錄所對應的資訊，該dentry 結構將會掛接到其父目錄中，也就是 中 "/" 目錄對應的 dentry 結構中，由鏈表實現這一關係。接下來會再分配一個 struct inode 結構。Inode 中的 i_sb 和 dentry 中的 d_sb 分別都指向 中的 sb，這樣看來，在同一檔案系統下建立新的目錄時並不需要重新分配一個超級塊結構，因為畢竟它們都屬於同一檔案系統，因此一個檔案系統只對應一個超級塊。

這樣，當調用 sys_mkdir 成功地在 VFS 的分類樹中建立立一個目錄 "/dev" 之後，在的基礎上，新的資料結構之間的關係便如 所示。 中顏色較深的兩個矩形塊 new_inode 和 new_entry 便是在sys_mkdir() 函數中新分配的記憶體結構，至於圖中的 mnt,sb,dentry,inode 等結構，仍為 中相應的資料結構，其相互之間的連結關係不變(圖中為避免過多的連結曲線，忽略了一些連結關係，如 mnt 和 sb,dentry之間的連結，讀者可在的基礎上參看)。

需要強調一點的是，既然 rootfs 檔案系統被 mount 到了 VFS 樹上，那麼它在 sys_mkdir 的過程中必然會參與進來，事實上在整個過程中，rootfs 檔案系統中的 ramfs_mkdir、ramfs_lookup 等函數都曾被調用過。

5.在 VFS 樹中掛載檔案系統

在本節中，將描述在 VFS 的分類樹中向其中某個目錄(安裝點 mount point)上掛載(mount)一個檔案系統的過程。

這一過程可簡單描述為：將某一裝置(dev_name)上某一檔案系統(file_system_type)安裝到VFS分類樹上的某一安裝點(dir_name)。它要解決的問題是：將對 VFS 分類樹中某一目錄的操作轉化為具體安裝到其上的實際檔案系統的對應操作。比如說，如果將 hda2 上的根檔案系統(假設檔案系統類型為 ext2)安裝到了前一節中建立立的 "/dev" 目錄上(此時，"/dev" 目錄就成為了安裝點)，那麼安裝成功之後應達到這樣的目的，即：對 VFS 檔案系統的 "/dev" 目錄執行 "ls" 指令，該條指令應能列出 hda2 上 ext2 檔案系統的根目錄下所有的目錄和檔案。很顯然，這裡的關鍵是如何將對 VFS 樹中 "/dev" 的目錄操作指令轉化為安裝在其上的 ext2 這一實際檔案系統中的相應指令。所以，接下來的敘述將抓住如何轉化這一核心問題。在敘述之前，讀者不妨自己設想一下 Linux 系統會如何解決這一問題。記住：對目錄或檔案的操作將最終由目錄或檔案所對應的 inode 結構中的 i_op 和 i_fop 所指向的函數表中對應的函數來執行。所以，不管最終解決方案如何，都可以設想必然要通過將對 "/dev" 目錄所對應的 inode 中 i_op 和 i_fop 的調用轉換到 hda2 上根檔案系統 ext2 中根目錄所對應的 inode 中 i_op 和 i_fop 的操作。

初始過程由 sys_mount() 系統調用函數發起，該函數原型聲明如下：

asmlinkage long sys_mount(char * dev_name, char * dir_name, char * type,unsigned long flags, void * data);

其中，參數 char *type 為標識將要安裝的檔案系統類型字串，對於 ext2 檔案系統而言，就是"ext2"。參數 flags 為安裝時的模式標識數，和接下來的 data 參數一樣，本文不將其做為重點。

為了協助讀者更好地理解這一過程，筆者用一個具體的例子來說明：我們準備將來自主硬碟第 2 分區(hda2)上的 ext2 檔案系統安裝到前面建立的 "/dev" 目錄中。那麼對於 sys_mount() 函數的調用便具體為：

sys_mount("hda2","/dev ","ext2",…)；

該函數在將這些來自使用者記憶體空間(user space)的參數拷貝到核心空間後，便調用 do_mount() 函數開始真正的安裝檔案系統的工作。同樣，為了便於敘述和講清楚主流程，接下來的說明將不嚴格按照具體的函數調用細節來進行。

do_mount() 函數會首先調用 path_lookup() 函數來得到安裝點的相關資訊，如同建立目錄過程中敘述的那樣，該安裝點的資訊最終記錄在 struct nameidata 類型的一個變數當中，為敘述方便，記該變數為nd。在本例中當 path_lookup() 函數返回時，nd 中記錄的資訊如下：nd.entry = new_entry; nd.mnt = mnt;這裡的變數 3 和 4 中所示。

然後，do_mount() 函數會根據調用參數 flags 來決定調用以下四個函數之一：do_remount()、 do_loopback()、do_move_mount()、do_add_mount()。

在我們當前的例子中，系統會調用 do_add_mount() 函數來向 VFS 樹中安裝點 "/dev " 安裝一個實際的檔案系統。在 do_add_mount() 中，主要完成了兩件重要事情：一是獲得一個新的安裝地區塊，二是將該新的安裝地區塊加入了安裝系統鏈表。它們分別是調用 do_kern_mount() 函數和 graft_tree() 函數來完成的。這裡的描述可能有點抽象，諸如安裝地區塊、安裝系統鏈表等，不過不用著急，因為它們都是筆者自己定義出來的概念，等一下到後面會有專門的圖表解釋，到時便會清楚。

do_kern_mount() 函數要做的事情，便是建立一新的安裝地區塊，具體的內容在前面的章節 VFS 分類樹的建立中已經敘述過，這裡不再贅述。

graft_tree() 函數要做的事情便是將 do_kern_mount() 函數返回的一 struct vfsmount 類型的變數加入到安裝系統鏈表中，同時 graft_tree() 還要將新分配的 struct vfsmount 類型的變數加入到一個hash表中，其目的我們將會在以後看到。

這樣，當 do_kern_mount() 函數返回時，在圖 4 的基礎上，新的資料結構間的關係將 5 所示。其中，紅圈地區裡面的資料結構便是被稱做安裝地區塊的東西，其中不妨稱 e2_mnt 為安裝地區塊的指標，藍色箭頭曲線即構成了所謂的安裝系統鏈表。

在把這些函數調用後形成的資料結構關係理清楚之後，讓我們回到本章節開始提到的問題，即將 ext2 檔案系統安裝到了 "/dev " 上之後，對該目錄上的操作如何轉化為對 ext2 檔案系統相應的操作。從圖 5上看到，對 sys_mount() 函數的調用並沒有直接改變 "/dev " 目錄所對應的 inode (即圖中的 new_inode變數)結構中的 i_op 和 i_fop 指標，而且 "/dev " 所對應的 dentry(即圖中的 new_dentry 變數)結構仍然在 VFS 的分類樹中，並沒有被從其中隱藏起來，相應地，來自 hda2 上的 ext2 檔案系統的根目錄所對應的 e2_entry 也不是如當初筆者所想象地那樣將 VFS 分類樹中的 new_dentry 取而代之，那麼這之間的轉化到底是如何?的呢？

請讀者注意下面的這段代碼：

while (d_mountpoint(dentry) && __follow_down(&nd->mnt, &dentry));

這段代碼在 link_path_walk() 函數中被調用，而 link_path_walk() 最終又會被 path_lookup() 函數調用，如果讀者閱讀過 Linux 關於檔案系統部分的代碼，應該知道 path_lookup() 函數在整個 Linux 繁瑣的檔案系統代碼中屬於一個重要的基礎性的函數。簡單說來，這個函數用於解析檔案路徑名，這裡的檔案路徑名和我們平時在應用程式中所涉及到的概念相同，比如在 Linux 的應用程式中 open 或 read 一個檔案 /home/windfly.cs 時，這裡的 /home/windfly.cs 就是檔案路徑名，path_lookup() 函數的責任就是對檔案路徑名中進行搜尋，直到找到目標檔案所屬目錄所對應的 dentry 或者目標直接就是一個目錄，筆者不想在有限的篇幅裡詳細解釋這個函數，讀者只要記住 path_lookup() 會返回一個目標目錄即可。

上面的代碼非常地不起眼，以至於初次閱讀檔案系統的代碼時經常會忽略掉它，但是前文所提到從 VFS 的操作到實際檔案系統操作的轉化卻是由它完成的，對 VFS 中實現的檔案系統的安裝可謂功不可沒。現在讓我們仔細剖析一下該段代碼：d_mountpoint(dentry) 的作用很簡單，它只是返回 dentry 中 d_mounted 成員變數的值。這裡的dentry 仍然還是 VFS 分類樹上的東西。如果 VFS 分類樹上某個目錄被安裝過一次，那麼該值為 1。對VFS 中的一個目錄可進行多次安裝，後面會有例子說明這種情況。在我們的例子中，"/dev" 所對應的new_dentry 中 d_mounted=1，所以 while 迴圈中第一個條件滿足。下面再來看__follow_down(&nd->mnt, &dentry)代碼做了什嗎？到此我們應該記住，這裡 nd 中的 dentry 成員就是中的 new_dentry，nd 中的 mnt成員就是中的 mnt，所以我們現在可以把 __follow_down(&nd->mnt, &dentry) 改寫成__follow_down(&mnt, &new_dentry)，接下來我們將 __follow_down() 函數的代碼改寫(只是去處掉一些不太相關的代碼，並且為了便於說明，在部分程式碼前加上了序號)如下：

static inline int __follow_down(struct vfsmount **mnt, struct dentry **dentry){struct vfsmount *mounted;[1]mounted = lookup_mnt(*mnt, *dentry);if (mounted) {[2]*mnt = mounted;[3]*dentry = mounted->mnt_root;return 1;}return 0;}

程式碼[1]中的 lookup_mnt() 函數用於尋找一個 VFS 分類樹下某一目錄最近一次被 mount 時的安裝地區塊的指標，在本例中最終會返回圖 5 中的 e2_mnt。至於尋找的原理，這裡粗略地描述一下。記得當我們在安裝 ext2 檔案系統到 "/dev" 時，在後期會調用 graft_tree() 函數，在這個函數裡會把圖 5 中的安裝地區塊指標 e2_mnt 掛到一 hash 表(Linux 2.4.20原始碼中稱之為 mount_hashtable)中的某一項，而該項的索引值就是由被安裝點所對應的 dentry(本例中為 new_dentry)和 mount(本例中為 mnt)所共同產生，所以自然地，當我們知道 VFS 樹中某一 dentry 被安裝過(該 dentry 變成為一安裝點)，而要去尋找其最近一次被安裝的安裝地區塊指標時，同樣由該安裝點所對應的 dentry 和 mount 來產生一索引值，以此值去索引 mount_hashtable，自然可找到該安裝點對應的安裝地區塊指標形成的鏈表的頭指標，然後遍曆該鏈表，當發現某一安裝地區塊指標，記為 p，滿足以下條件時：

(p->mnt_parent == mnt && p->mnt_mountpoint == dentry)

P 便為該安裝點所對應的安裝地區塊指標。當找到該指標後，便將 nd 中的 mnt 成員換成該安裝地區塊指標，同時將 nd 中的 dentry 成員換成安裝地區塊中的 dentry 指標。在我們的例子中，e2_mnt->mnt_root成員指向 e2_dentry，也就是 ext2 檔案系統的 "/" 目錄。這樣，當 path_lookup() 函數搜尋到 "/dev"時，nd 中的 dentry 成員為 e2_dentry，而不再是原來的 new_dentry，同時 mnt 成員被換成 e2_mnt，轉化便在不知不覺中完成了。

現在考慮一下對某一安裝點多次安裝的情況，同樣作為例子，我們假設在 "/dev" 上安裝完一個 ext2檔案系統後，再在其上安裝一個 ntfs 檔案系統。在安裝之前，同樣會對安裝點所在的路徑調用path_lookup() 函數進行搜尋，但是這次由於在 "/dev" 目錄上已經安裝過了 ext2 檔案系統，所以搜尋到最後，由 nd 返回的資訊是：nd.dentry = e2_dentry, nd.mnt = e2_mnt。由此可見，在第二次安裝時，安裝點已經由 dentry 變成了 e2_dentry。接下來，同樣地，系統會再分配一個安裝地區塊，假設該安裝地區塊的指標為 ntfs_mnt，地區塊中的 dentry 為 ntfs_dentry。ntfs_mnt 的父指標指向了e2_mnt，mnfs_mnt 中的 mnt_root 指向了代表 ntfs 檔案系統根目錄的 ntfs_dentry。然後，系統通過 e2_dentry和 e2_mnt 來產生一個新的 hash 索引值，利用該值作為索引，將 ntfs_mnt 加入到 mount_hashtable 中，同時將 e2_dentry 中的成員 d_mounted 值設定為 1。這樣，安裝過程便告結束。

讀者可能已經知道，對同一安裝點上的最近一次安裝會隱藏起前面的若干次安裝，下面我們通過上述的例子解釋一下該過程：

在先後將 ext2 和 ntfs 檔案系統安裝到 "/dev" 目錄之後，我們再調用 path_lookup() 函數來對"/dev" 進行搜尋，函數首先找到 VFS 分類樹下的安裝點 "/dev" 所對應的 dentry 和 mnt，此時它發現dentry 成員中的 d_mounted 為 1，於是它知道已經有檔案系統安裝到了該 dentry 上，於是它通過 dentry 和 mnt 來產生一個 hash 值，通過該值來對 mount_hashtable 進行搜尋，根據安裝過程，它應該能找到 e2_mnt 指標並返回之，同時原先的 dentry 也已經被替換成 e2_dentry。回頭再看一下前面已經提到的下列代碼：while (d_mountpoint(dentry) && __follow_down(&nd->mnt, &dentry)); 當第一次迴圈結束後, nd->mnt 已經是 e2_mnt，而 dentry 則變成 e2_dentry。此時由於 e2_dentry 中的成員 d_mounted 值為 1，所以 while 迴圈的第一個條件滿足，要繼續調用 __follow_down() 函數，這個函數前面已經剖析過，當它返回後 nd->mnt 變成了 ntfs_mnt，dentry 則變成了 ntfs_dentry。由於此時 ntfs_dentry 沒有被安裝過其他檔案，所以它的成員 d_mounted 應該為 0，迴圈結束。對 "/dev" 發起的 path_lookup() 函數最終返回了 ntfs 檔案系統根目錄所對應的 dentry。這就是為什麼 "/dev" 本身和安裝在其上的 ext2 都被隱藏的原因。如果此時對 "/dev" 目錄進行一個 ls 命令，將返回安裝上去的 ntfs 檔案系統根目錄下所有的檔案和目錄。

6. 安裝根檔案系統

有了前面章節 4 的基礎，理解 Linux 下根檔案系統的安裝並不困難，因為不管怎麼樣，安裝一個檔案系統到 VFS 中某一安裝點的過程原理畢竟都是一樣的。

這個過程大致是：首先要確定待安裝的 ext2 檔案系統的來源，其次是確定 ext2 檔案系統在 VFS中的安裝點，然後便是具體的安裝過程。

關於第一問題，Linux 2.4.20 的核心另有一大堆的代碼去解決，限於篇幅，筆者不想在這裡去具體說明這個過程，大概記住它是要解決到哪裡去找要安裝的檔案系統的就可以了，這裡我們不妨就認為要安裝的根檔案系統就來自於主硬碟的第一分區 hda1.

關於第二個問題，Linux 2.4.20 的核心把來自於 hda1 上 ext2 檔案系統安裝到了 VFS 分類樹中的"/root" 目錄上。其實，把 ext2 檔案系統安裝到 VFS 分類樹下的哪個安裝點並不重要(VFS 的根目錄除外)，只要是這個安裝點在 VFS 樹中是存在的，並且核心對它沒有另外的用途。如果讀者喜歡，盡可以自己在 VFS 中建立一個 "/Windows" 目錄，然後將 ext2 檔案系統安裝上去作為將來使用者進程的根目錄，沒有什麼不可以的。問題的關鍵是要將進程的根目錄和當前工作目錄設定好，因為畢竟只用使用者進程才去關心現實的檔案系統，要知道筆者的這篇稿子可是要存到硬碟上去的。

在 Linux 下，設定一個進程的當前工作目錄是通過系統調用 sys_chdir() 進行的。初始化期間，Linux 在將 hda1 上的 ext2 檔案系統安裝到了 "/root" 上後，通過調用 sys_chdir("/root") 將當前進程，也就是 init_task 進程的當前工作目錄(pwd)設定為 ext2 檔案系統的根目錄。記住此時 init_task進程的根目錄仍然是圖 3 中的 dentry，也就是 VFS 樹的根目錄，這顯然是不行的，因為以後 Linux 世界中的所有進程都由這個 init_task 進程派生出來，無一例外地要繼承該進程的根目錄，如果是這樣，意味著使用者進程從根目錄搜尋某一目錄時，實際上是從 VFS 的根目錄開始的，而事實上卻是從 ext2 的根檔案開始搜尋的。這個矛盾的解決是靠了在調用完 mount_root() 函數後，系統調用的下面兩個函數：

sys_mount(".", "/", NULL, MS_MOVE, NULL);sys_chroot(".");

其主要作用便是將 init_task 進程的根目錄轉化成安裝上去的 ext2 檔案系統的根目錄。有興趣的讀者可以自行去研究這一過程。

所以在使用者空間下，更多地情況是只能見到 VFS 這棵大樹的一葉，而且還是被安裝過檔案系統了的，實際上對使用者空間來說還是不可見。我想，VFS 更多地被核心用來實現自己的功能，並以系統調用的方式提供過使用者進程使用，至於在其上實現的不同檔案系統的安裝，也只是其中的一個功能罷了。

應用程式層的開發不需要關心VFS源碼的具體實現，只需要知道VFS對外的各類檔案系統的介面函數即可。

Reference

http://www.ibm.com/developerworks/cn/views/linux/libraryview.jsp

來源於網路，轉載請註明出處：http://blog.csdn.net/suool/article/details/38172057