
我目前正在閱讀 W. Richard Stevens 所著的《高級 UNIX 程式設計》一書,在那裡我讀到 UNIX 上的所有檔案都有編號,並且建立檔案名稱只是為了方便使用者。輸入目錄後,系統會在號碼中搜尋輸入的名稱。
我心想,他們怎麼查這個號碼?文件是否按名稱排序存儲,以便可以透過二分搜尋找到它們?或者他們只是將新文件附加到列表末尾?
答案1
有許多不同的檔案系統格式,它們在不同場景下的效能(大目錄與小目錄、讀與寫、並發存取等)、設計簡單性(錯誤的可能性、開發工作量等)、磁碟開銷(空間)之間做出了不同的折衷用於文件內容以外的東西)等。
較舊的檔案系統(例如UFS、FFS,外部2, 原來的外部3,...)傾向於將目錄儲存為條目數組(每個條目包含檔案名稱、索引節點號以及可能的一些附加元資料)並進行線性搜尋。新文件將添加到數組中的第一個空閒條目處;如果沒有空閒條目,則首先擴大數組。這會導致大型目錄的效能不佳。
較新的檔案系統(例如外部3與dir_index
選項,外部4,茲夫斯,BTFS,賴塞爾夫斯,高頻FS,高頻FS+,...)傾向於將目錄儲存為具有對數時間查找的資料結構,某種平衡搜尋樹,哈希表或兩者的組合(哈希的平衡搜尋樹) - 通常是B樹。這使得檔案系統程式碼更加複雜,但在大型目錄下保持良好的效能。
答案2
該數字稱為索引節點。 Ext4 是較受歡迎的 Linux 檔案系統類型之一,它使用哈希樹,請參閱kernel.org - Ext4 磁碟佈局。
哈希樹的更多詳細資訊位於維基百科。
答案3
這取決於檔案系統。很久以前,Unix目錄本質上是一個由16位元組記錄組成的文件,其中兩個位元組為內部編號,14個位元組為文件名稱。這就是舊時檔案名稱 14 個字元限制的原因。記錄未排序,因此需要對文件進行線性搜尋。
更現代的檔案系統(例如 Linux 的 Ext4)具有哈希表來加速搜尋。
答案4
學究警告:描述不完整。檔案名稱不能說只是為了方便使用者。檔案名稱原來是極為在基於 UNIX 的系統中很重要。
索引節點號沒有意義,因為它們是由檔案系統模組選擇的。最初,他們在磁碟上儲存的索引節點表中確定了一個插槽。系統的其他部分需要存取具有特定含義的文件,例如/dev/tty1
或/etc/passwd
。
如果不讓您使用特定的字詞,「便利」就太微不足道了,無法描述該機制,該機制用於提供使用者介面來選擇命令(例如cat
或ed
按名稱)。
如果沒有檔案名稱目錄,您很快就必須為索引節點號發明一些非常相似的名稱註冊表來支援這些用途。
目錄條目.
也..
有特殊的意義。虛擬檔案系統例如proc
使用檔案名稱提供它們自己的含義,例如/proc/1/comm
提供有關進程1的資訊 VFS還允許使用不同的檔案系統,這些檔案系統不必基於unix,並且可能無法使用相同的確切概念索引節點號。
ZFS 似乎認為檔案名稱和 inode 元資料(如權限)都屬於單獨的層。我還不明白這有什麼好處。當用於儲存嵌套檔案系統時,它似乎更像是一種為檔案等效物件提供不同效能旋鈕的方法。
此外,使用者通常無法透過索引節點號開啟檔案。如果可以,您將無法透過包含director{y,ies}的權限來控制對檔案的存取...
也許看待最後一點的另一種方式是它是目錄的特性。目錄的整個原理是映射檔案名,因此如果沒有它,它們就不會產生任何效果。
等等,你說,它們仍然可以作為文件引用的容器,也就是「硬連結」。您可以在多個目錄中列出文件;如果檔案仍保留在另一個目錄中,則從一個目錄中刪除檔案 ( unlink
) 並不會真正刪除該檔案。硬連結是 unix 實作中一個有趣的部分,但據我所知,他們從未真正找到任何實用程式!它們通常被認為只是造成混亂的機會。這是一個公開實作細節的範例,因為它使提供有趣的功能變得非常容易,而無需真正考慮該功能是否必要。與「十億美元的錯誤」類似,儘管這種特殊的設計缺陷並沒有那麼危險。
也就是說,值得注意的是目錄保證其包含的文件存在的方式。如果您想實作其他一些系統來識別文件,則必須考慮刪除文件可能會留下一個引用不存在文件的條目,甚至是一個被分配了相同 inode 的新的不相關文件。