重新匯出 NFS 檔案系統

概述

透過 NFS 重新匯出 NFS 檔案系統是可能的。然而，此功能具有諸多限制。在嘗試之前，我們建議您仔細研究，以確定它是否符合您的目的。

下面將討論當前已知的限制。

需要“fsid=”，crossmnt 已損壞

任何 NFS 檔案系統重新匯出時，我們都要求使用“fsid=”匯出選項。您可以使用“uuidgen -r”生成一個唯一的引數。

“crossmnt”匯出不會傳播“fsid=”，因此它不允許遍歷到其他 NFS 檔案系統；如果您希望匯出掛載在已匯出檔案系統下的 NFS 檔案系統，則需要顯式匯出它們，併為每個檔案系統分配自己唯一的“fsid=”選項。

重啟恢復

當重新匯出伺服器重啟時，NFS 協議的正常重啟恢復機制不起作用，因為源伺服器尚未重啟，因此它不在寬限期內。由於源伺服器不在寬限期內，它無法保證在鎖丟失和任何嘗試恢復它們之間檔案不會被更改。這同樣適用於委託和任何相關鎖。客戶端不允許從重新匯出伺服器獲取檔案鎖或委託，任何嘗試都將失敗並顯示操作不支援。

檔案控制代碼限制

如果原始伺服器對給定物件使用 X 位元組的檔案控制代碼，則重新匯出伺服器對重新匯出物件的檔案控制代碼將是 X+22 位元組，並向上舍入到最接近的四位元組倍數。

結果必須符合 RFC 規定的檔案控制代碼大小限制

NFSv2	32 位元組
NFSv3	64 位元組
NFSv4	128 位元組

因此，例如，只有當原始伺服器提供的檔案控制代碼適合 10 位元組時，您才能透過 NFSv2 重新匯出檔案系統——這不太可能。

通常，在不詢問伺服器供應商的情況下，無法知道 NFS 伺服器發出的最大檔案控制代碼大小。

但下表給出了一些示例。第一列是 Linux 伺服器匯出給定檔案系統時檔案控制代碼的典型長度，第二列是該 NFS 匯出被另一個 Linux 主機重新匯出後的長度

	檔案控制代碼長度	重新匯出後
ext4	28 位元組	52 位元組
xfs	32 位元組	56 位元組
btrfs	40 位元組	64 位元組

因此，重新匯出後，所有檔案都將適合 NFSv3 或 NFSv4 檔案控制代碼，但沒有一個可以透過 NFSv2 重新匯出。

不過，Linux 伺服器的檔案控制代碼比這更復雜；例如

• (非預設)“subtreecheck”匯出選項通常需要在檔案控制代碼中額外佔用 4 到 8 位元組。

• 如果您匯出檔案系統的子目錄(而不是匯出檔案系統根目錄)，通常也會增加 4 到 8 位元組。

• 如果您透過 NFSv2 匯出，knfsd 通常會使用一個較短的檔案系統識別符號，可節省 8 位元組。

• 匯出的根目錄使用較短的檔案控制代碼。

如您所見，128 位元組的 NFSv4 檔案控制代碼足夠大，因此您不太可能在使用 NFSv4 重新匯出從 Linux 伺服器匯出的任何檔案系統時遇到麻煩。一般來說，如果原始伺服器也支援 NFSv3，那麼您可能沒問題。透過 NFSv3 重新匯出可能更冒險，而透過 NFSv2 重新匯出可能永遠無法工作。

有關 Linux 檔案控制代碼結構的更多詳細資訊，最佳參考是原始碼和註釋；特別是請參閱

• include/linux/exportfs.h:enum fid_type

• include/uapi/linux/nfsd/nfsfh.h:struct nfs_fhbase_new

• fs/nfsd/nfsfh.c:set_version_and_fsid_type

• fs/nfs/export.c:nfs_encode_fh

開啟 DENY 位被忽略

NFS 從 NFSv4 開始支援從 Windows 借鑑的 ALLOW 和 DENY 位，它們允許您例如以禁止其他讀開啟或寫開啟的模式開啟檔案。Linux 客戶端不使用它們，並且伺服器的支援一直不完整：它們僅針對其他 NFS 使用者強制執行，而不針對本地訪問匯出檔案系統的程序。重新匯出伺服器也不會將它們傳遞給原始伺服器，因此它們不會在不同重新匯出伺服器的客戶端之間強制執行。