概述

Linux 下有 3 種“拷貝”，分別是 ln，cp，mv，這 3 個(gè)命令貌似都能 copy 出一個(gè)新的文件出來。

細(xì)心的小伙伴看到我給 “拷貝” 打上了雙引號(hào)？因?yàn)?Linux 的這 3 個(gè)命令有極大的區(qū)別，雖然用戶看起來是拷貝出了新文件。

你是否曾經(jīng)遇到過以下問題，想通原因了嗎？：

ln 創(chuàng)建鏈接文件，軟鏈接可以跨文件系統(tǒng)，硬鏈接跨文件系統(tǒng)會(huì)報(bào)錯(cuò)，為什么？；

mv 好像有時(shí)候快，有時(shí)候非常慢，有些時(shí)候還會(huì)殘留垃圾，為什么？；

cp 拷貝數(shù)據(jù)有時(shí)快，有時(shí)候非常慢，源文件和目標(biāo)文件所占物理空間竟然不一致？

本篇文章看完，希望你以上問題不再有疑問，從容使用 ln，mv，cp 命令。

溫馨提示：

以下我們只討論文件的簡(jiǎn)單操作，關(guān)于目錄操作或者復(fù)雜參數(shù)的操作不在我們本次主題以內(nèi)，我們忽略；

coreutils 庫(kù)的代碼版本用的是 8.3；

我們來看下簡(jiǎn)單的 3 個(gè)命令操作。首先在執(zhí)行以下命令之前，準(zhǔn)備一個(gè)不小的 test 的普通文件（比如 1G ）。

“拷貝”命令一：ln

# 創(chuàng)建一個(gè)軟鏈接文件

ln -s 。/test 。/test_soft_link

# 創(chuàng)建一個(gè)硬連接文件

ln 。/test 。/test_hard_link

你會(huì)發(fā)現(xiàn)當(dāng)前目錄出現(xiàn)了兩個(gè)新文件 test_soft_link ，test_hard_link 。并且你會(huì)發(fā)現(xiàn)拷貝速度好快？為什么呢？

“拷貝”命令二：mv

把 test 文件“拷貝”到 。/backup/ 目錄

mv 。/test 。/backup/

更神奇的是，好像 copy 一個(gè) 1 G 的文件，速度也賊快？

“拷貝”命令三：cp

把 test 文件“拷貝”到 。/backup/ 目錄

cp 。/test 。/backup/

上面我們看到，好像 ln，mv，cp 這 3 個(gè)命令都是“拷貝”？好像都進(jìn)行了數(shù)據(jù)復(fù)制出了新的文件？

答案：當(dāng)然不是。這 3 個(gè)看起來都是復(fù)制出了新文件，但其實(shí)天壤之別。我們一個(gè)個(gè)來揭秘。

在揭秘這 3 個(gè)命令之前，我們必須先復(fù)習(xí)文件的基礎(chǔ)知識(shí)點(diǎn)，Linux 的文件和目錄的關(guān)系。

Linux 的文件和目錄

在 深度剖析 Linux cp 的秘密 一文中，我們?cè)敿?xì)剖析了文件系統(tǒng)的形態(tài)。有幾個(gè)關(guān)鍵知識(shí)點(diǎn)：

文件系統(tǒng)內(nèi)有 3 個(gè)關(guān)鍵區(qū)域：超級(jí)塊區(qū)域，inode 區(qū)域，數(shù)據(jù) block 區(qū)域；

其中一個(gè) inode 和一個(gè)文件對(duì)應(yīng)，包含了文件的元數(shù)據(jù)信息；

一個(gè) inode 有唯一的編號(hào)，可以理解成就是單調(diào)遞增的整數(shù)。比如 1，2，3，4，5，6，，，，；

關(guān)于上面，我們注意到 inode 其實(shí)標(biāo)識(shí)的是一個(gè)平坦的結(jié)構(gòu)，inode 索引到數(shù)據(jù) data 區(qū)域，每個(gè) inode 都有唯一編號(hào)。

問題來了：Linux 的目錄是一個(gè)倒掛的樹形結(jié)構(gòu)呀，為什么上面說 inode 是平坦的結(jié)構(gòu)？如下：

Linux 的文件確實(shí)是樹形結(jié)構(gòu)，inode 也確實(shí)是平坦的結(jié)構(gòu)。你會(huì)感覺到因?yàn)槭且驗(yàn)橹肮室夂雎粤艘粋€(gè)幾個(gè)東西：目錄文件和 dentry 項(xiàng)。這是兩個(gè)非常重要的概念，我們逐個(gè)解釋下。

文件系統(tǒng)中其實(shí)有兩種文件類型，分為：

普通文件（這里把鏈接文件包含在普通文件以內(nèi)）

目錄文件

可以通過 inode-》i_mode 字段，使用 S_ISREG，S_ISDIR 這兩個(gè)宏來判斷是哪個(gè)類型。普通文件很容易理解，就是普通的數(shù)據(jù)文件，inode 里面存儲(chǔ)元數(shù)據(jù)，inode 可以索引到 block，block 里面存儲(chǔ)用戶的數(shù)據(jù)。目錄文件 inode 存儲(chǔ)元數(shù)據(jù)，block 里面存儲(chǔ)的是目錄條目。目錄條目是什么樣子的東西？

舉個(gè)形象的例子：在當(dāng)前 testdir 目錄下，有 dir1，dir2，dir3 這三個(gè)文件。假設(shè) dir1 的 inode 編號(hào)是 1024，dir2 是 1025，dir3 是 1026。

那么現(xiàn)實(shí)是這樣的：

testdir 這個(gè)目錄首先會(huì)對(duì)應(yīng)有一個(gè) inode，inode-》i_mode 的類型是目錄，并且還會(huì)有 block 塊，通過 inode-》i_blocks 能索引到這些 block；

block 里面存儲(chǔ)的內(nèi)容很簡(jiǎn)單，是一個(gè)個(gè)目錄條目，內(nèi)核的名字縮寫為 dirent，每一個(gè) dirent 本質(zhì)就是一個(gè) 文件名字 到 inode 編號(hào)的映射，所以，testdir 這個(gè)目錄文件的 block 里存了 3 條記錄 ［dir1， 1024］，［dir2， 1025］，［dir3， 1026］；

所以，目錄到底是什么呢？就存儲(chǔ)形態(tài)而已，目錄也是文件，存儲(chǔ)的是 名字 到 inode number 的映射表。dirent 其實(shí)就是 directory entry 的縮寫。

好像還沒講到樹形結(jié)構(gòu)？

其實(shí)已經(jīng)講了一半了，樹形結(jié)構(gòu)的數(shù)據(jù)結(jié)構(gòu)基礎(chǔ)已經(jīng)有了，就是目錄文件和 dirent 的實(shí)現(xiàn)。

假設(shè)葉子結(jié)點(diǎn)的為普通文件

針對(duì)開篇的圖，其實(shí)磁盤上存儲(chǔ)了 3 個(gè)目錄文件

這個(gè)時(shí)候，讀者朋友你是不是都可以用筆畫出一個(gè)樹形結(jié)構(gòu)了，內(nèi)存的樹形結(jié)構(gòu)也是這么來的。通過磁盤的映射數(shù)據(jù)構(gòu)造出來。在內(nèi)存中，這個(gè)樹形結(jié)構(gòu)的節(jié)點(diǎn)用 dentry 來表示（通常翻譯成目錄項(xiàng)，但是筆者認(rèn)為這個(gè)翻譯很容易讓人誤解）。

以下是筆者從內(nèi)核精簡(jiǎn)出來的 dentry 結(jié)構(gòu)體，通過這個(gè)總結(jié)到幾個(gè)信息：

dentry 綁定到唯一一個(gè) inode 結(jié)構(gòu)體；

dentry 有父，子，兄弟的索引路徑，有這個(gè)就足夠在內(nèi)存中構(gòu)建一個(gè)樹了，并且事實(shí)也確實(shí)如此；

struct dentry {

// 。。。

struct dentry *d_parent; /* 父節(jié)點(diǎn) */

struct qstr d_name; // 名字

struct inode *d_inode; // inode 結(jié)構(gòu)體

struct list_head d_child; /* 兄弟節(jié)點(diǎn) */

struct list_head d_subdirs; /* 子節(jié)點(diǎn) */

};

所以，看到現(xiàn)在理解了嗎？父、子 指針，這就是經(jīng)典的樹形結(jié)構(gòu)需要的字段呀。目錄文件類型為樹形結(jié)構(gòu)提供了存儲(chǔ)到磁盤持久化的一種形態(tài)，是一種 map 表項(xiàng)的形態(tài)，每一個(gè)表項(xiàng)我們叫做 dirent 。文件樹的結(jié)構(gòu)在內(nèi)存中以 dentry 結(jié)構(gòu)體體現(xiàn)。

劃重點(diǎn)：仔細(xì)理解下 dirent 和 dentry 的概念和形態(tài)，仔細(xì)理解磁盤的數(shù)據(jù)形態(tài)和內(nèi)存的數(shù)據(jù)結(jié)構(gòu)形態(tài)，后面要考的。

ln 命令

ln 是 Linux 的基礎(chǔ)命令之一，是 link 的縮寫，顧名思義就是跟鏈接文件相關(guān)的一個(gè)命令。一般語法如下：

ln ［OPTION］。。。 TARGET LINK_NAME

ln 可以用來創(chuàng)建一個(gè)鏈接文件，有趣的是，鏈接文件有兩個(gè)不同的類別：

軟鏈接文件

硬鏈接文件

1 什么是軟鏈接文件？

無論是軟鏈接還是硬鏈接都是“鏈接”文件，也就是說，通過這個(gè)鏈接文件都能找到背后的那個(gè)“源文件”。首先說結(jié)論：

軟鏈接文件是一個(gè)全新的文件，有獨(dú)立的 inode，有自己的 block ，而這個(gè)文件類型是“鏈接文件”的類型而已；

這個(gè)軟鏈接文件的內(nèi)容是一段 path 路徑，這個(gè)路徑直接指向源文件；

所以，你明白了嗎？軟鏈接文件就是一個(gè)文件而已，文件里面存儲(chǔ)的是一個(gè)路徑字符串。所以軟鏈接文件可以非常靈活，鏈接文件本身和源解耦，只通過一段路徑字符串尋路。

所以，軟鏈接文件是可以跨文件系統(tǒng)創(chuàng)建的。

有興趣的小伙伴可以去看源碼實(shí)現(xiàn)，在 coreutils 庫(kù)里，調(diào)用棧如下：

main -》 do_link -》 force_symlinkat -》 symlinkat

也就是說最終調(diào)用的是系統(tǒng)調(diào)用 symlinkat 來完成創(chuàng)建，而這個(gè) symlinkat 系統(tǒng)調(diào)用在內(nèi)核由不同的文件系統(tǒng)實(shí)現(xiàn)。舉個(gè)例子，如果是 minix 文件系統(tǒng)，那么對(duì)應(yīng)的函數(shù)就是 minix_symlink。minix_symlink 這個(gè)函數(shù)上來就是新建一個(gè) inode ，然后在對(duì)應(yīng)的目錄文件中添加一個(gè) dirent 。來來來，我們看一眼 minix_symlink 的主干代碼：

static int minix_symlink（struct inode * dir， struct dentry *dentry，

const char * symname）

{

// 。。。

// 新建一個(gè) inode，inode 類型為 S_IFLNK 鏈接類型

inode = minix_new_inode（dir， S_IFLNK | 0777， &err）;

if （！inode）

goto out;

// 填充鏈接文件內(nèi)容

minix_set_inode（inode， 0）;

err = page_symlink（inode， symname， i）;

if （err）

goto out_fail;

// 綁定 dentry 和 inode

err = add_nondir（dentry， inode）;

//。。。

}

劃重點(diǎn)：軟鏈接文件是新建了一個(gè)文件，文件類型是鏈接文件，文件內(nèi)容就是一段字符串路徑。分配新的 inode，內(nèi)存對(duì)應(yīng)新的 dentry ，當(dāng)然了，也新增了一個(gè) dirent 。軟鏈文件可以跨越不同的文件系統(tǒng)。

2 什么是硬鏈接文件？

現(xiàn)在我們知道了，軟鏈接文件怎么找到源文件的？通過路徑找到的，路徑就存儲(chǔ)在軟鏈接文件中。硬鏈接文件又怎么辦到的呢？

硬鏈接很神奇，硬鏈接其實(shí)是新建了一個(gè) dirent 而已。下面是重點(diǎn)：

硬鏈接文件其實(shí)并沒有新建文件（也就是說，沒有消耗 inode 和 文件所需的 block 塊）；

硬鏈接其實(shí)是修改了當(dāng)前目錄所在的目錄文件，加了一個(gè) dirent 而已，這個(gè) dirent 用一個(gè)新的 name 名字指向原來的 inode number；

重點(diǎn)來了，由于新舊兩個(gè) dirent 都是指向同一個(gè) inode，那么就導(dǎo)致了一個(gè)限制：不能跨文件系統(tǒng)。因?yàn)椋煌募到y(tǒng)的 inode 管理都是獨(dú)立的。

感興趣的同學(xué)可以試下，跨文件系統(tǒng)創(chuàng)建硬鏈接就會(huì)報(bào)告如下錯(cuò)誤：Invalid cross-device link

sh-4.4# ln /dev/shm/source.txt 。/dest.txt

ln： failed to create hard link ‘。/dest.txt’ =》 ‘/dev/shm/source.txt’： Invalid cross-device link

有興趣的小伙伴可以去看源碼實(shí)現(xiàn)，在 coreutils 庫(kù)里，調(diào)用棧如下：

main -》 do_link -》 force_linkat -》 linkat

也就是說最終調(diào)用的是系統(tǒng)調(diào)用 linkat 來完成創(chuàng)建，而這個(gè) linkat 系統(tǒng)調(diào)用在內(nèi)核由不同的文件系統(tǒng)實(shí)現(xiàn)。舉個(gè)例子，如果是 minix 文件系統(tǒng)，那么對(duì)應(yīng)的函數(shù)就是 minix_link。這個(gè)函數(shù)從內(nèi)存上來講是把一個(gè) dentry 和 inode 關(guān)聯(lián)起來。從磁盤數(shù)據(jù)結(jié)構(gòu)上來講，會(huì)在對(duì)應(yīng)目錄文件中增加一個(gè) dirent 項(xiàng)。

劃重點(diǎn)：硬鏈接只增加了一個(gè) dirent 項(xiàng)，只修改了目錄文件而已。不涉及到 inode 數(shù)量的變化。新的 name 指向原來的 inode。

mv 命令

mv 是 move 的縮寫，從效果上來看，是把源文件搬移到另一個(gè)位置。

你是否思考過 mv 命令內(nèi)部是怎么實(shí)現(xiàn)的呢？

是把源文件拷貝到目標(biāo)位置，然后刪除源文件嗎？所以，說 mv 貌似也是“拷貝”？

其實(shí)，并不是，準(zhǔn)確的說不完全是。

對(duì)于 mv 的討論，要拆分成源和目的文件是否在同一個(gè)文件系統(tǒng)。

1 源 和 目的 在同一個(gè)文件系統(tǒng)

mv 命令的核心操作是系統(tǒng)調(diào)用 rename ，rename 從內(nèi)核實(shí)現(xiàn)來說只涉及到元數(shù)據(jù)的操作，只涉及到 dirent 的增刪（當(dāng)然不同的文件系統(tǒng)可能略有不同，但是大致如是）。通常操作是刪除源文件所在目錄文件中的 dirent，在目標(biāo)目錄文件中添加一個(gè)新的 dirent 項(xiàng)。

劃重點(diǎn)：inode number 不變，inode 不變，不增不減，還是原來的 inode 結(jié)構(gòu)體，所以數(shù)據(jù)完全沒有拷貝。

mv 的調(diào)用棧如下，感興趣的可以自己調(diào)試。

main -》 renameat2

main -》 movefile -》 do_move -》 copy -》 copy_internal -》 renameat2

我們用例子來直觀看下，首先準(zhǔn)備好一個(gè) source.txt 文件，用 stat 命令看下元數(shù)據(jù)信息：

sh-4.4# stat source.txt

File： source.txt

Size： 0 Blocks： 0 IO Block： 4096 regular empty file

Device： 78h/120d Inode： 3156362 Links： 1

Access： （0644/-rw-r--r--） Uid： （ 0/ root） Gid： （ 0/ root）

我們看到 inode 編號(hào)是：3156362 。然后執(zhí)行 mv 命令：

sh-4.4# mv source.txt dest.txt

然后 stat 看下 dest.txt 文件的信息：

sh-4.4# stat dest.txt

File： dest.txt

Size： 0 Blocks： 0 IO Block： 4096 regular empty file

Device： 78h/120d Inode： 3156362 Links： 1

Access： （0644/-rw-r--r--） Uid： （ 0/ root） Gid： （ 0/ root）

發(fā)現(xiàn)沒？inode 編號(hào)還是 3156362 。

2 源 和 目的 在不同的文件系統(tǒng)

還記得之前我們提過，由于硬鏈接是直接在目錄文件中添加一個(gè) dirent，名字直接指向源文件的 inode ，不同文件系統(tǒng)都是獨(dú)立的一套 inode 管理系統(tǒng)，所以硬鏈接不能跨文件系統(tǒng)。

那么問題來了，mv 遇到跨文件系統(tǒng)的場(chǎng)景呢，怎么處理？是否還是 rename ？

舉個(gè)例子，如下命令，源和目的是不同的文件系統(tǒng)。我虛擬機(jī)的掛載點(diǎn)如下：

sh-4.4# df -h

Filesystem Size Used Avail Use% Mounted on

overlay 59G 3.5G 52G 7% /

tmpfs 64M 0 64M 0% /dev

shm 64M 0 64M 0% /dev/shm

我故意挑選 /home/qiya/testdir 和 /dev/shm/ ，這兩個(gè)目錄分別對(duì)應(yīng)了 “/” 和 “/dev/shm/” 的掛載點(diǎn)的文件系統(tǒng)，分屬兩個(gè)不同的文件系統(tǒng)。我們先提前看下源文件的信息（主要是 inode 信息）：

sh-4.4# stat /dev/shm/source.txt

File： /dev/shm/source.txt

Size： 0 Blocks： 0 IO Block： 4096 regular empty file

Device： 7fh/127d Inode： 163990 Links： 1

Access： （0644/-rw-r--r--） Uid： （ 0/ root） Gid： （ 0/ root）

我們執(zhí)行以下 mv 命令：

sh-4.4# mv /dev/shm/source.txt /home/qiya/testdir/dest.txt

然后看下目的文件信息：

sh-4.4# stat dest.txt

File： dest.txt

Size： 0 Blocks： 0 IO Block： 4096 regular empty file

Device： 78h/120d Inode： 3155414 Links： 1

Access： （0644/-rw-r--r--） Uid： （ 0/ root） Gid： （ 0/ root）

對(duì)比有沒有發(fā)現(xiàn)，inode 的信息是不一樣的，inode number 是不一樣的（是不是跟上面同一文件系統(tǒng)下的 mv 現(xiàn)象不一致）什么原因呢？我下面一一道來，從原理出剖析。

當(dāng)系統(tǒng)調(diào)用 rename 的時(shí)候，如果源和目的不在同一文件系統(tǒng)時(shí)，會(huì)報(bào)告 EXDEV 的錯(cuò)誤碼，提示該調(diào)用不能跨文件系統(tǒng)。

#define EXDEV 18 /* Cross-device link */

所以，rename 是不能用于跨文件系統(tǒng)的，這個(gè)時(shí)候怎么辦？

劃重點(diǎn)：這個(gè)時(shí)候操作分成兩步走，先 copy ，后 remove 。

第一步：走不了 rename ，那么就退化成 copy ，也就是真正的拷貝。讀取源文件，寫入目標(biāo)位置，生成一個(gè)全新的目標(biāo)文件副本；

這里調(diào)用的 copy_reg 的函數(shù)封裝（要知道這個(gè)函數(shù)是 cp 命令的核心函數(shù)，在 深度剖析 Linux cp 的秘密 有深入剖析過 ）；

ln，mv，cp 是在 coreutils 庫(kù)里的命令，公用函數(shù)本身就是可以復(fù)用的；

第二步：刪除源文件，使用 rm 函數(shù)刪除；

思考問題：mv 跨文件系統(tǒng)的時(shí)候，如果第一步成功了，第二步失敗了（比如沒有刪除權(quán)限）會(huì)怎么樣？

會(huì)導(dǎo)致垃圾。也就是說，目標(biāo)處創(chuàng)建了一個(gè)新文件，源文件并沒有刪除。這個(gè)小實(shí)驗(yàn)有興趣的可以試下。

cp 命令

cp 命令才是真正的數(shù)據(jù)拷貝命令，即拷貝元數(shù)據(jù)，也會(huì)拷貝數(shù)據(jù)。cp 命令也是我之前花了萬字篇幅分析的命令，詳細(xì)可見：深度剖析 Linux cp 的秘密。這里就不再贅述，下面提煉出關(guān)于拷貝的 3 種模式。

涉及到數(shù)據(jù)拷貝的，關(guān)鍵有個(gè) --sparse 參數(shù)，可以控制拷貝數(shù)據(jù)的 IO 次數(shù)。

1 auto 模式

重點(diǎn)：跳過文件空洞。是 cp 默認(rèn)的模式

cp src.txt dest.txt

2 always 模式

重點(diǎn)：跳過文件空洞，還會(huì)跳過全 0 數(shù)據(jù)，是空間最省的模式。

cp --sparse=always src.txt dest.txt

3 never 模式

重點(diǎn)：無腦拷貝，從頭拷貝到尾，不識(shí)別物理空洞和全 0 數(shù)據(jù)，是速度最慢的一種模式。

cp --sparse=never src.txt dest.txt

復(fù)用之前畫的這 3 張圖，很形象的體現(xiàn)了 cp 的行為。

總結(jié)

目錄文件是一種特殊的文件，可以理解成存儲(chǔ)的是 dirent 列表。dirent 只是名字到 inode 的映射，這個(gè)是樹形結(jié)構(gòu)的基礎(chǔ)；

常說目錄樹在內(nèi)存中確實(shí)是一個(gè)樹的結(jié)構(gòu)，每個(gè)節(jié)點(diǎn)由 dentry 結(jié)構(gòu)體表示；

ln -s 創(chuàng)建軟鏈接文件，軟鏈接文件是一個(gè)獨(dú)立的新文件，有一個(gè)新的 inode ，有新的 dentry，文件類型為 link，文件內(nèi)容就是一條指向源的路徑，所以軟鏈的創(chuàng)建可以無視文件系統(tǒng)，跨越山河；

ln 默認(rèn)創(chuàng)建硬連接，硬鏈接文件只在目錄文件里添加了一個(gè)新 dirent 項(xiàng) 《新name：原inode》，文件 inode 還是和原文件同一個(gè)，所以硬鏈接不能跨文件系統(tǒng)（因?yàn)椴煌奈募到y(tǒng)是獨(dú)立的一套 inode 管理方式，不同的文件系統(tǒng)實(shí)例對(duì) inode number 的解釋各有不同）；

ln 命令貌似創(chuàng)建出了新文件，但其實(shí)不然，ln 只跟元數(shù)據(jù)相關(guān)，涉及到 dirent 的變動(dòng)，不涉及到數(shù)據(jù)的拷貝，起不到數(shù)據(jù)備份的目的；

mv 其實(shí)是調(diào)用 rename 調(diào)用，在同一個(gè)文件系統(tǒng)中不涉及到數(shù)據(jù)拷貝，只涉及到元數(shù)據(jù)變更（ dirent 的增刪 ），所以速度也很快。但如果 mv 的源和目的在不同的文件系統(tǒng)，那么就會(huì)退化成真正的 copy ，會(huì)涉及到數(shù)據(jù)拷貝，這個(gè)時(shí)候速度相對(duì)慢一些，慢成什么樣子？就跟 cp 命令一樣；

cp 命令才是真正的數(shù)據(jù)拷貝命令，速度可能相對(duì)慢一些，但是 cp 命令有 --spare 可以優(yōu)化拷貝速度，針對(duì)空洞和全 0 數(shù)據(jù)，可以跳過，從而針對(duì)稀疏文件可以節(jié)省大量磁盤 IO；

編輯：jq