目录
概述
Linux的文件和目录
ln命令
1哪些是软链接文件？
2哪些是硬链接文件？
mv命令
1源和目的在同一个文件系统
2源和目的在不同的文件系统
cp命令
1auto模式
2always模式
3never模式
总结
概述
Linux下有3种“拷贝”，分别是ln，cplinux 复制快捷键，mv，这3个命令似乎都能copy出一个新的文件下来。
悉心的男子伴看见我给“拷贝”打上了双冒号？由于Linux的这3个命令有极大的区别，毕竟用户看上去是拷贝出了新文件。
你是否当初遇见过以下问题，想通缘由了吗？：
ln创建链接文件，软链接可以跨文件系统，硬链接跨文件系统会报错，为何？；mv似乎有时侯快，有时侯特别慢linux 复制快捷键，有些时侯就会残留垃圾，为何？；cp拷贝数据有时快，有时侯特别慢，源文件和目标文件所占数学空间居然不一致？
本篇文章看完，希望你以上问题不再有疑惑鸟哥的linux私房菜，从容使用ln，mv，cp命令。
温情提示：
以下我们只讨论文件的简单操作，关于目录操作或则复杂参数的操作不在我们本次主题以内，我们忽视；
coreutils库的代码版本用的是8.3；
我们来看下简单的3个命令操作。首先在执行以下命令之前，打算一个不小的test的普通文件（例如1G）。
"拷贝"命令一：ln
# 创建一个软链接文件
ln -s ./test ./test_soft_link
# 创建一个硬连接文件
ln ./test ./test_hard_link
你会发觉当前目录出现了两个新文件test_soft_link，test_hard_link。但是你会发觉拷贝速率好快？为何呢？
"拷贝"命令二：mv
把test文件"拷贝"到./backup/目录
mv ./test ./backup/
更神奇的是，似乎copy一个1G的文件，速率也贼快？
“拷贝”命令三：cp
把test文件"拷贝"到./backup/目录
cp ./test ./backup/
前面我们看见，似乎ln，mv，cp这3个命令都是“拷贝”？似乎都进行了数据复制出了新的文件？
答案：其实不是。这3个看上去都是复制出了新文件，但毕竟天壤之别。我们一个个来解密。
在解密这3个命令之前，我们必须先备考文件的基础知识点，Linux的文件和目录的关系。
Linux的文件和目录
在深度分析Linuxcp的秘密一文中，我们详尽分析了文件系统的形态。有几个关键知识点：
文件系统内有3个关键区域：超级块区域，inode区域，数据block区域；其中一个inode和一个文件对应，包含了文件的元数据信息；一个inode有惟一的编号，可以理解成就是单调递增的整数。诸如1，2，3，4，5，6，，，，；
关于里面，我们注意到inode虽然标示的是一个平坦的结构，inode索引到数据data区域，每位inode都有惟一编号。
问题来了：Linux的目录是一个倒挂的树状结构呀，为何里面说inode是平坦的结构？如下：
Linux的文件确实是树状结构，inode也确实是平坦的结构。你会觉得到由于是由于之前故意忽视了一个几个东西：目录文件和dentry项。这是两个特别重要的概念，我们挨个解释下。
文件系统中虽然有两种文件类型，分为：
可以通过inode->i_mode数组，使用S_ISREG，S_ISDIR这两个宏来判定是那个类型。普通文件很容易理解，就是普通的数据文件，inode上面储存元数据，inode可以索引到block，block上面储存用户的数据。目录文件inode储存元数据，block上面储存的是目录条目。目录条目是哪些样子的东西？
举个形象的事例：在当前testdir目录下，有dir1，dir2，dir3这三个文件。假定dir1的inode编号是1024，dir2是1025，dir3是1026。
这么现实是这样的：
testdir这个目录首先会对应有一个inode，inode->i_mode的类型是目录，但是都会有block块，通过inode->i_blocks能索引到这种block；block上面储存的内容很简单，是一个个目录条目，内核的名子简写为dirent，每一个dirent本质就是一个文件名子到inode编号的映射，所以，testdir这个目录文件的block里存了3条记录[dir1,1024]，[dir2,1025]，[dir3,1026]；
所以，目录究竟是哪些呢？就储存形态而已，目录也是文件，储存的是名子到inodenumber的映射表。dirent虽然就是directoryentry的简写。
似乎还没提到树状结构？
虽然早已讲了一半了，树状结构的数据结构基础早已有了，就是目录文件和dirent的实现。
假定叶子结点的为普通文件
针对开篇的图，虽然c盘上储存了3个目录文件
这个时侯，读者同学你是不是都可以用笔划出一个树状结构了，显存的树状结构也是如此来的。通过c盘的映射数据构造下来。在显存中，这个树状结构的节点用dentry来表示（一般翻译成目录项，并且笔者觉得这个翻译很容易让人误会）。
以下是笔者从内核精简下来的dentry结构体，通过这个总结到几个信息：
dentry绑定到惟一一个inode结构体；dentry有父，子，兄弟的索引路径，有这个就足够在显存中建立一个树了，但是事实也确实这么；
struct dentry {
// ...
struct dentry *d_parent; /* 父节点 */
struct qstr d_name; // 名字
struct inode *d_inode; // inode 结构体
struct list_head d_child; /* 兄弟节点 */
struct list_head d_subdirs; /* 子节点 */
};
所以，见到现今理解了吗？父、子表针，这就是精典的树状结构须要的数组呀。目录文件类型为树状结构提供了储存到c盘持久化的一种形态，是一种map表项的形态，每一个表项我们称作dirent。文件树的结构在显存中以dentry结构体彰显。
划重点：仔细理解下dirent和dentry的概念和形态，仔细理解c盘的数据形态和显存的数据结构形态，前面要考的。
ln命令
ln是Linux的基础命令之一，是link的简写，顾名思义就是跟链接文件相关的一个命令。通常句型如下：
ln [OPTION]... TARGET LINK_NAME
ln可以拿来创建一个链接文件，有趣的是，链接文件有两个不同的类别：
1哪些是软链接文件？
无论是软链接还是硬链接都是“链接”文件，也就是说，通过这个链接文件都能找到背后的那种“源文件”。首先说推论：
所以，你明白了吗？软链接文件就是一个文件而已，文件上面储存的是一个路径字符串。所以软链接文件可以十分灵活，链接文件本身和源前馈，只通过一段路径字符串寻路。
所以，软链接文件是可以跨文件系统创建的。
有兴趣的男子伴可以去看源码实现，在coreutils库里，调用栈如下：
main -> do_link -> force_symlinkat -> symlinkat
也就是说最终调用的是系统调用symlinkat来完成创建，而这个symlinkat系统调用在内核由不同的文件系统实现。举个反例，假如是minix文件系统，这么对应的函数就是minix_symlink。minix_symlink这个函数上来就是新建一个inode，之后在对应的目录文件中添加一个dirent。来来来，我们看一眼minix_symlink的主干代码：
static int minix_symlink(struct inode * dir, struct dentry *dentry,
const char * symname)
{
// ...
// 新建一个 inode，inode 类型为 S_IFLNK 链接类型
inode = minix_new_inode(dir, S_IFLNK | 0777, &err);
if (!inode)
goto out;
// 填充链接文件内容
minix_set_inode(inode, 0);
err = page_symlink(inode, symname, i);
if (err)
goto out_fail;
// 绑定 dentry 和 inode
err = add_nondir(dentry, inode);
//...
}
划重点：软链接文件是新建了一个文件，文件类型是链接文件，文件内容就是一段字符串路径。分配新的inode，显存对应新的dentry，其实了，也新增了一个dirent。软链文件可以跨越不同的文件系统。
2哪些是硬链接文件？
如今我们晓得了，软链接文件如何找到源文件的？通过路径找到的，路径就储存在软链接文件中。硬链接文件又如何办到的呢？
硬链接很神奇，硬链接虽然是新建了一个dirent而已。下边是重点：
硬链接文件或许并没有新建文件（也就是说，没有消耗inode和文件所需的block块）；硬链接虽然是更改了当前目录所在的目录文件，加了一个dirent而已，这个dirent用一个新的name名子指向原先的inodenumber；
重点来了，因为新旧两个dirent都是指向同一个inode，这么就造成了一个限制：不能跨文件系统。由于，不同文件系统的inode管理都是独立的。
感兴趣的朋友可以试下，跨文件系统创建硬链接都会报告如下错误：Invalidcross-devicelink
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
有兴趣的男子伴可以去看源码实现，在coreutils库里，调用栈如下：
main -> do_link -> force_linkat -> linkat
也就是说最终调用的是系统调用linkat来完成创建常用linux系统，而这个linkat系统调用在内核由不同的文件系统实现。举个反例，假如是minix文件系统，这么对应的函数就是minix_link。这个函数从显存上来讲是把一个dentry和inode关联上去。从c盘数据结构上来讲，会在对应目录文件中降低一个dirent项。
划重点：硬链接只降低了一个dirent项，只更改了目录文件而已。不涉及到inode数目的变化。新的name指向原先的inode。
mv命令
mv是move的简写，从疗效上来看，是把源文件搬动到另一个位置。
你是否思索过mv命令内部是如何实现的呢？
是把源文件拷贝到目标位置，之后删掉源文件吗？所以，说mv其实也是“拷贝”？
虽然，并不是，确切的说不完全是。
对于mv的讨论，要拆分成源和目的文件是否在同一个文件系统。
1源和目的在同一个文件系统
mv命令的核心操作是系统调用rename，rename从内核实现来说只涉及到元数据的操作，只涉及到dirent的增删（其实不同的文件系统可能略有不同，并且大致如是）。一般操作是删掉源文件所在目录文件中的dirent，在目标目录文件中添加一个新的dirent项。
划重点：inodenumber不变，inode不变，不增不减，还是原先的inode结构体，所以数据完全没有拷贝。
mv的调用栈如下，感兴趣的可以自己调试。
main -> renameat2
main -> movefile -> do_move -> copy -> copy_internal -> renameat2
我们用事例来直观看下，首先打算好一个source.txt文件，用stat命令看下元数据信息：
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编号是：3156362。之后执行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)
发觉没？inode编号还是3156362。
2源和目的在不同的文件系统
还记得之前我们提过，因为硬链接是直接在目录文件中添加一个dirent，名子直接指向源文件的inode，不同文件系统都是独立的一套inode管理系统，所以硬链接不能跨文件系统。
这么问题来了，mv遇见跨文件系统的场景呢，如何处理？是否还是rename？
举个反例，如下命令，源和目的是不同的文件系统。我虚拟机的挂载点如下：
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/，这两个目录分别对应了"/"和"/dev/shm/"的挂载点的文件系统，分属两个不同的文件系统。我们先提早看下源文件的信息（主要是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)
我们执行以下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)
对比有没有发觉，inode的信息是不一样的，inodenumber是不一样的（是不是跟前面同一文件系统下的mv现象不一致）哪些缘由呢？我下边一一道来，从原理出分析。
当系统调用rename的时侯，假如源和目的不在同一文件系统时，会报告EXDEV的错误码，提示该调用不能跨文件系统。
#define EXDEV 18 /* Cross-device link */
所以，rename是不能用于跨文件系统的，这个时侯如何办？
划重点：这个时侯操作分成两步走，先copy，后remove。
第一步：走不了rename，这么就退化成copy，也就是真正的拷贝。读取源文件，写入目标位置，生成一个全新的目标文件副本；这儿调用的copy_reg的函数封装（要晓得这个函数是cp命令的核心函数，在深度分析Linuxcp的秘密有深入探讨过）；ln，mv，cp是在coreutils库里的命令，公用函数本身就是可以复用的；第二步：删掉源文件，使用rm函数删掉；
思索问题：mv跨文件系统的时侯，假如第一步成功了，第二步失败了（例如没有删掉权限）会如何样？
会造成垃圾。也就是说，目标处创建了一个新文件，源文件并没有删掉。这个小实验有兴趣的可以试下。
cp命令
cp命令才是真正的数据拷贝命令，即拷贝元数据，也会拷贝数据。cp命令也是我之前花了万字篇幅剖析的命令，详尽可见：深度分析Linuxcp的秘密。这儿就不再赘言，下边提炼出关于拷贝的3种模式。
涉及到数据拷贝的，关键有个--sparse参数，可以控制拷贝数据的IO次数。
1auto模式
重点：跳过文件空洞。是cp默认的模式
cp src.txt dest.txt
2always模式
重点：跳过文件空洞，就会跳过全0数据，是空间最省的模式。
cp --sparse=always src.txt dest.txt
3never模式
重点：无脑拷贝，从头拷贝到尾，不辨识化学空洞和全0数据，是速率最慢的一种模式。
cp --sparse=never src.txt dest.txt
复用之前画的这3张图，很形象的彰显了cp的行为。
总结
目录文件是一种特殊的文件，可以理解成储存的是dirent列表。dirent只是名子到inode的映射，这个是树状结构的基础；常说目录树在显存中确实是一个树的结构，每位节点由dentry结构体表示；ln-s创建软链接文件，软链接文件是一个独立的新文件，有一个新的inode，有新的dentry，文件类型为link，文件内容就是一条指向源的路径，所以软链的创建可以无视文件系统，跨越山河；ln默认创建硬联接，硬链接文件只在目录文件里添加了一个新dirent项，文件inode还是和原文件同一个，所以硬链接不能跨文件系统（由于不同的文件系统是独立的一套inode管理方法，不同的文件系统实例对inodenumber的解释各有不同）；ln命令其实创建出了新文件，但毕竟不然，ln只跟元数据相关，涉及到dirent的变动，不涉及到数据的拷贝，起不到数据备份的目的；mv虽然是调用rename调用，在同一个文件系统中不涉及到数据拷贝，只涉及到元数据变更（dirent的增删），所以速率也很快。但若果mv的源和目的在不同的文件系统，这么都会退化成真正的copy，会涉及到数据拷贝，这个时侯速率相对慢一些，慢成哪些样子？就跟cp命令一样；cp命令才是真正的数据拷贝命令，速率可能相对慢一些，而且cp命令有--spare可以优化拷贝速率，针对空洞和全0数据，可以跳过，因而针对稀疏文件可以节约大量c盘IO；
