一場機器遷移引起的思考
最近團隊一台機器老化了，准備做全量遷移，一不小心，就把100多個G的/data目錄放到了新機器的/data/data目錄下，上愁了，怎么削減一層data目錄呢？難倒像Windows一樣剪切過來嗎？可是有100多個G啊？！抱着試試的心態，運行mv命令，沒想到系統瞬間就完成了。為什么Linux可以這么快速剪切呢？這一切都要從Linux對文件的管理機制說起的。
inode是什么
要想理解inode，就要從Linux的文件存儲開始說起。
文件存儲在硬盤上，硬盤上最小的存儲單位叫做“扇區”（sector）,每一個扇區存儲512字節。
操作系統讀取硬盤的時候，不會一個個扇區地讀取，這樣效率太低，而是一次性連續讀取多個扇區，即一次性讀取一個"塊"（block）。這種由多個扇區組成的"塊"，是文件存取的最小單位。"塊"的大小，最常見的是4KB，即連續八個 sector組成一個 block。
文件數據都儲存在"塊"中，那么很顯然，我們還必須找到一個地方儲存文件的元信息，比如文件的創建者、文件的創建日期、文件的大小等等。這種儲存文件元信息的區域就叫做inode，中文譯名為"索引節點"。
每一個文件都有對應的inode，里面包含了與該文件有關的一些信息。
inode包含文件的元信息，具體來說有以下內容：
- 文件的字節數。
- 文件擁有者的User ID。
- 文件的Group ID。
- 文件的讀、寫、執行權限。
- 文件的時間戳，共有三個：ctime指inode上一次變動的時間，mtime指文件內容上一次變動的時間，atime指文件上一次打開的時間。
- 鏈接數，即有多少文件名指向這個inode。
- 文件數據block的位置。
想要查看文件的inode信息，可以通過stat命令。
每一個inode都有一個編號，就像上面，inode編號為5278，操作系統就靠inode編號來識別文件。
強調一點，Linux不使用文件名，而是使用inode編號識別不同文件。
對於用戶來說，通過文件名打開了文件；但是對於系統來說，首先，系統找到文件名對應的inode編號，通過這個編號獲取了inode信息，再根據這個信息，找到文件數據所在的block，讀取數據並顯示。
目錄文件
Linux中，目錄（directory）本身也是一種文件。我們打開目錄，其實就是打開了目錄本身這個文件。
目錄文件的結構很簡單，就是一系列目錄項（dirent）的列表。每個目錄項包括兩部分：所包含文件的文件名，以及該文件名對應的inode編號。也就是說，目錄文件其實就是包含了文件名與inode編號的映射的集合。
通過ls -i命令可以查看文件名和inode編號。
理解了上面這些，就能理解目錄的權限。目錄文件的讀權限（r）和寫權限（w），都是針對目錄文件本身。由於目錄文件內只有文件名和inode號碼，所以如果只有讀權限，只能獲取文件名，無法獲取其他信息，因為其他信息都儲存在inode節點中，而讀取inode節點內的信息需要目錄文件的執行權限（x）。
mv命令與inode
當運行mv命令后，構成這個文件的實際內容，不管是inode還是硬盤數據，都沒有被轉移。被改變的，僅僅是目錄的映射（文件名與inode之間的映射）。
如果目標文件和原文件在同一個文件系統，mv會在目錄映射表新建一行，刪除帶有源文件名的原有目錄行。
如果目標文件和原文件不在同一個文件系統，mv就相當於cp與rm命令的組合。
cp命令：分配一個沒有被使用的inode編號，在inode表中增加新項目，然后在目錄映射表中新增一行，關聯文件名與inode編號。
rm命令：遞減鏈接計數，釋放inode編號。然后把數據塊掛載到可用空間，再刪除目錄映射表中相關行。
我們可以看到，其中底層數據並沒有被刪除，只是被標記為了可用，當數據塊被另一個文件利用時，原來的數據就會被覆蓋。
inode帶來的特殊現象（熱更新）
由於inode號碼與文件名分離，這種機制導致了一些Unix/Linux系統特有的現象。
有時，文件名包含特殊字符，無法正常刪除。這時，直接刪除inode節點，就能起到刪除文件的作用。
移動文件或重命名文件，只是改變文件名，不影響inode號碼。
打開一個文件以后，系統就以inode號碼來識別這個文件，不再考慮文件名。因此，通常來說，系統無法從inode號碼得知文件名。
第3點使得軟件更新變得簡單，可以在不關閉軟件的情況下進行更新，不需要重啟。因為系統通過inode號碼，識別運行中的文件，不通過文件名。更新的時候，新版文件以同樣的文件名，生成一個新的inode，不會影響到運行中的文件。等到下一次運行這個軟件的時候，文件名就自動指向新版文件，舊版文件的inode則被回收。
參考：
https://zh.wikipedia.org/wiki/Inode
https://www.cnblogs.com/peida/archive/2012/10/27/2743022.html