Linux NFS filehandle 筆記

  最近在看 Linux NFS 相關的程式碼,趁還有點記憶的時候來筆記一下,這篇主要筆記 NFS filehandle 的運作機制。

基本概念

  filehandle 是 NFS 操作遠端檔案系統的最基礎機制之一,用來表示一個對應的文件,從 C 語言的角度來看,他很類似 fopen 所得到的 file descriptor,對於使用者而言,filehandle/file descriptor 是一種不透明(opaque)的資料結構,使用者不需要知道他實際上存了些什麼,只要知道有他就可以操作到對應的檔案。

  相較於直接使用檔案路徑來表示一個檔案,使用 filehandle 有兩個主要的優點及目的,首先,filehandle 通常是一個較小且較為固定的大小,對網路傳輸有其便利性,其次是他總是代表相同的檔案,就算對象檔案被重新命名或是被移動過,他還是能找回原本的那個檔案。

filehandle 結構

  filehandle 主要包含了兩個主要成份,分別是代表匯出路徑(export point)檔案系統的 fsid,以及代表檔案系統內一個檔案的 fileid,我們可以看 Linux 核心內是如何定義他:

struct nfs_fhbase_new {
	__u8		fb_version;	/* 代表版本,目前固定為 1, even => nfs_fhbase_old */
	__u8		fb_auth_type;	/* deprecated 沒有被使用 */
	__u8		fb_fsid_type;
	__u8		fb_fileid_type;
	__u32		fb_auth[1];	/* deprecated 沒有被使用 */
/*	__u32		fb_fsid[0]; floating */
/*	__u32		fb_fileid[0]; floating */
};

  fb_auth_type 及 fb_auth 已經是 deprecated 沒有被使用,因此主要的部份就只剩下 fsid 及 fileid。

fsid

  fb_fsid_type 用來表示後面的 fb_fsid 如何表示一個匯出的檔案系統,這兩個值我沒完全搞懂他到底是如何在 user space 和 kernel space 之間傳遞,之後要找時間再深入看一下,但就我目前認知的是,他是由 nfs-utils 內的 mountd 來做初始設定。

  剛開始我也很疑惑為何是 mountd,但仔細思考了一下,給掌管匯出路徑的 mountd 來指定 fsid 也是合理的。也許會問,平常更新 /etc/exports 時都是透過 exportfs 來重新載入,難道不是 exportfs 在管理匯出嗎?但實際上 exportfs 比較像是 mountd 的輔助程式,真正和核心溝通的還是 mountd。

  mountd 在決定 fsid 時大致上有二種方式,第一種是使用者在 /etc/exports 內直接指定 fsid=NUM,第二種是使用 UUID,而 UUID 又有兩種取得方式,第一種,也是優先選擇的是檔案系統掛載的 blkid,第二種是透過 statfs 取得 filesystem 的 UUID。

  不同的 filesystem 適用於不同的 UUID 取得方式,例如 FAT 透過 statfs 得到的 fsid 是 device number,但 device number 是可能會改變的,因此並不恰當。相反的例子是 btrfs 的 subvolume,每個 subvolume 有不同的 fsid,但共用同一個 blkid,btrfs 使用 fsid 會有他的意義。

  相關的程式碼位於 nfs-utils/utils/mountd/cache.c 內的 uuid_by_patch 函式。

fileid

  fileid 的編碼(encode) 則是由每個檔案系統自行實作,這也是一個檔案系統要支援 NFS 最基本需要實作的部份,相關的函式介面定義在以下結構,最核心的函數為 encode_fh、fh_to_dentry、fh_to_parent 及 get_parent:

struct export_operations {
	int (*encode_fh)(struct inode *inode, __u32 *fh, int *max_len,
			struct inode *parent);
	struct dentry * (*fh_to_dentry)(struct super_block *sb, struct fid *fid,
			int fh_len, int fh_type);
	struct dentry * (*fh_to_parent)(struct super_block *sb, struct fid *fid,
			int fh_len, int fh_type);
	int (*get_name)(struct dentry *parent, char *name,
			struct dentry *child);
	struct dentry * (*get_parent)(struct dentry *child);

	/* 在這以下的函數只有 xfs 有實作 */
	int (*commit_metadata)(struct inode *inode);

	/* 以下幾個函數和 pnfs 有關,但我還不確定用途 */
	int (*get_uuid)(struct super_block *sb, u8 *buf, u32 *len, u64 *offset);
	int (*map_blocks)(struct inode *inode, loff_t offset,
			  u64 len, struct iomap *iomap,
			  bool write, u32 *device_generation);
	int (*commit_blocks)(struct inode *inode, struct iomap *iomaps,
			     int nr_iomaps, struct iattr *iattr);
};

  encode_fh 將一個檔案的 inode 轉為 fileid,如果 parent 不為 NULL 的話,必須將該檔案的 parent 目錄 inode 也一並存入 fileid。這個函數有預設實作,會存 32bits inode number 及 inode generation,如以下結構:

struct {
	u32 ino;
	u32 gen;
	u32 parent_ino;
	u32 parent_gen;
} i32;

  我們可以在核心的 fs/exportfs/expfs.c 找到這個預設的實作:

static int export_encode_fh(struct inode *inode, struct fid *fid,
		int *max_len, struct inode *parent)
{
	int len = *max_len;
	int type = FILEID_INO32_GEN;

	// 確認提供的空間夠大,不夠大的話則將所需要的大小透過 max_len 回傳給呼叫者
	if (parent && (len < 4)) {
		*max_len = 4;
		return FILEID_INVALID; // 0xFF 代表無效的 FILEID
	} else if (len < 2) {
		*max_len = 2;
		return FILEID_INVALID;
	}

	// 填入檔案的 inode number 及 generation
	len = 2;
	fid->i32.ino = inode->i_ino;
	fid->i32.gen = inode->i_generation;

	// 如果呼叫者有提供 parent,則將 parent 一併編入 fileid
	if (parent) {
		fid->i32.parent_ino = parent->i_ino;
		fid->i32.parent_gen = parent->i_generation;
		len = 4;
		type = FILEID_INO32_GEN_PARENT;
	}
	*max_len = len;	// 將實際使用的大小從 max_len 回傳給呼叫者
	return type;	// 回傳編碼的方式
}

  每個檔案系統根據其需求可自行編碼不同的內容及大小,只要能確保找到唯一對應的檔案即可,例如 btrfs 至少得多存 root object ID,因為他的 inode number 在不同 subvolume 內是可能重複的。

  fh_to_dentry 實作 fileid 的解碼工作,給定一個 fileid,回傳檔案的 dentry,這個就沒有預設實作了,每個檔案系統要根據他的 layout 方式取回對應的 dentry,之後 nfs server 便可以透過該 dentry 進行檔案操作。

  fh_to_parent 實作 fileid 的另一部份解碼工作,如果 parent 資訊有存入 fileid,則回傳該 fileid 內所紀錄的 parent dentry。get_parent 則是給定一個 dentry,回傳該他的 parent dentry。

  需要 parent 資訊的主要原因是 subtree_check,當 NFS 伺服端啟用 subtree_check 後,進行檔案操作前會先經過權限的檢查,要進行權限檢查,就勢必要能取回該檔案的完整路徑。NFS 取回完整路徑的方式是透過 fh_to_parent 及 get_parent 這兩個函數,先利用 fh_to_parent 取得檔案的 parent dentry,再透過 get_parent 一路找回根目錄。

  已經有 get_parent 函數了為何還要 fh_to_parent 呢?熟悉 ext4 檔案系統架構者就會知道,只有一個檔案的 inode number 是沒辦法直接取得他所在的目錄的,所以才需要在編碼時將他的 parent 一並編入。但如果已知一個目錄,檔案系統就可以透過 ‘..’ 一路找回根目錄了。

Lin Chieh ( Jayce )

Lin Chieh ( Jayce )
設定目標、執行、回顧,人生就是在一次又一次的短跑衝刺中不斷成長前進!一個機械系的資訊人心得分享。

Visual Studio Code Remote - WSL 安裝教學

Visual Studio Code Remote - WSL可以讓 VS Code Server 實際執行在 WSL 裡面,只留 UI 介面在 Windows。這對某些插件非常有用,因為有些東西跑在 Linux 環境是比較容易的。另外 Visual Studio Code Remote 系列還包含 Remote - SSH 模式,這東西就更猛了,如果你的 Build Machine 是遠端的 Linux Server ,他可以直接透過 SSH 跑在 Linux Server 端,像是檔案搜尋等動作,直接執行在遠端 Linux 就會比透過 Samba 或 NFS 快上很多。 Continue reading