来源 | IOT物联网小镇
作者 | 道哥
最近，看到很多文章都在介绍 Linux 中的文件系统，其中就包括：inode 节点、软链接、硬链接等重要的概念。
于是就有小伙伴私信问我：这些概念我都懂，但是我能利用他们来完成什么工作呢？
或者说，在哪些情况下，软链接和硬链接能够提供提供更好的解决方案呢？
这篇文章我们就来简单梳理一下，软链接和硬链接的几个使用场景。
什么是索引节点
什么是硬链接
什么是软链接
软链接应用之：灵活切换不同版本的目标程序
软链接应用之：动态库版本管理
软链接应用之：快捷方式
硬链接应用之：从不同角度对文件进行分类
硬链接应用之：文件多人共享
硬链接应用之：文件备份
在 Linux 系统中，我们可以把一个文件看做 3 个组成部分：
文件名：从用户角度来描述一个文件;
文件内容：也就是文件中存储的那些数据;
文件的描述信息：文件的类型、所有者、创建时间等等，可以称之为元信息;
可以简单的做一个类比：
文件本身的内容，可以看做一个实实在在的人。
文件的描述信息，可以看做是派出所里的户籍卡。
户籍卡上记录了一个人的姓名、年龄、住址等信息，警察叔叔通过这个户籍卡，就知道这个人的一切描述信息，除了你脑袋里的知识。
回到计算机中，文件的所有信息都需要存储在硬盘上，因此就要对硬盘进行区域划分：不同的区域存储不同类型的数据，这就是文件系统的重要作用。
在 Linux 系统使用的 ext2/ext3 文件系统中，从硬盘上划分一块区域，用来存放文件本身的内容(数据)，这块区域按照一个最小单位：块(block)来进行划分。
然后从硬盘上划分出另一块区域，专门用来存放所有文件的描述信息。
每一个文件的描述信息，都用一个名为索引节点(inode)的数据结构来表示，所有文件的 inode 就统一放在这块硬盘区域中。
就像户籍卡上记录了一个人的住址一样，一个文件的索引节点(inode)中，也记录了这个文件的所有描述信息，包括：文件类型、所有者、创建时间等待，当然也包括文件内容存储在硬盘的哪些块(block)中。
当我们调用打开文件 API 函数的时候，操作系统首先根据传入的文件路径，找到这个文件的 inode，然后进行一系列的权限检查操作，最后从 inode 中获得这个文件的内容存储在哪些块(block)中，从而可以对文件的内容进行读取、写入操作。
文件名称只是给我们用户来使用的，操作系统只是通过 inode 节点，来对文件进行管理的。
当我们创建一个新文件的时候，就同时创建了这个文件对应的 inode 节点。
当我们删除一个文件的时候，就同时删除了这个文件对应的 inode 节点。
此时，文件本身内容所在的那个块中，数据并不会被抹除掉，因此有些数据恢复软件就是利用这个特点来进行数据找回。
一句话总结：索引节点(inode)就像户籍卡，操作系统通过 inode 来管理所有的文件。
刚才已经说到，每一个文件都对应一个 inode 节点。
例如有一个文件 a.txt，文件内容长度是 1024 个字节，存放在硬盘上的某个块(block)中，假设就是第 10000 个块吧。
那么这个文件对应的 inode 节点中，就会把 10000 这个块记录下来。
同时，它还有一个 links 字段，表示：当前这个 inode 对应一个文件，此时 inode.links 的值为 1。
此时，如果我们用另一个文件名 a_hard_link.txt，也来表示 a.txt 这个文件。
也就是说：虽然我们用了 2 个文件名称，但是本质上指向同一个文件，内容都指向第 10000 个块中存储的文件内容。
Linux 系统中提供了硬链接来支持这样的目的，它仅仅是把 inode 节点中的 links 字段的值 加1 即可，也就是 inode.links 的值变成了 2。
硬链接的操作指令是：
$ ln a.txt b.txt
基于硬链接，用户就可以用不同的文件名来访问同一个文件，所有的操作最终修改的都是同一个文件。
如果仅仅从用户的角度来看，好像我们是在操作不同的文件，但是这些文件具有自动同步的功能。
这个行为有点类似于网盘：
在云存储中有一个文件 hello.txt，然后我有两台电脑 A 和 B，这两台电脑会把云端的文件 hello.txt 都创建一个镜像文件在本地，就好像这个文件就在自己的硬盘上一样。
当我在电脑 A 上操作 hello.txt 时，电脑 B 中的同名文件会自动更新。
因此，从行为上来看，硬链接就相当于是：文件拷贝 + 自动同步。
再来看一下硬链接文件的删除操作。
在执行 $ ln a.txt a_hard_link.txt 指令之后，该文件对应的 inode 节点中，links 的值为 2。
如果我们删除 a.txt，操作系统会把该文件对应的 inode 中的 links 值减1，结果为 1，操作系统发现不为 0，因此并不会删掉这个 inode。
如果我们再删除 a_hard_link.txt，操作系统再次执行 inode.links 减1 动作，发现值变成了 0，于是就把这个 inode 删除了，于是这个文件就彻底不存在了。
这就相当于把一个人的户籍卡给注销掉了，从户籍管理角度看，这个人就不存在了。即使存在，也是一个黑户。
硬链接存在 2 个限制：
不允许用户给目录创建硬链接，即：用户不可以，操作系统可以(想一下每个目录下的 . 和 ..);
只有在同一个文件系统中的文件，才能创建硬链接，也就是说：不能跨文件系统;
为了克服硬链接的 2 个限制，软链接被引入进来了。
软链接也叫符号链接，它是一个独立的文件。
软链接文件的内容是一个文本字符串，存储的是目标文件(即：链接到的文件)的路径名。
这个路径名可以指向任意一个文件系统的任意文件或者目录，甚至可以指向一个不存在的文件。
与创建硬链接不同的是：当我们创建了一个软链接之后，操作系统会创建一个新的 inode 来表示这个软链接文件。
例如有一个文件 a.txt，我们创建一个软链接 a_soft_link.txt 来指向它：
$ ln -s a.txt a_soft_link.txt
此时，a.txt 和 a_soft_link.txt 各自都有自己的 inode 节点。
图中的绿色虚线，就表示软链接文件中的文件路径。
正因为软链接文件中存储的仅仅是目标文件的路径字符串，所以可以表示任意一个文件系统中的文件，或者是目录。
当我们打开文件软链接 a_soft_link.txt 时，操作系统从 a_soft_link.txt 对应的 inode 数据结构中发现：这是一个软链接文件。
于是操作系统就根据其中的路径信息，找到 a.txt 的 inode 节点，从而对最终的目标文件进行操作。
再来看一下软链接文件的删除操作。
如果我们把目标文件 a.txt 删除掉之后，inode 节点会被删除掉，就相当于它的户籍卡被注销掉了。
此时再次打开软链接 a_soft_link.txt 时，虽然其中的路径信息仍然存在，但是系统此时却找不到 a.txt 对应的 inode 节点了。
因此，软链接就类似于与 Windows 系统中的快捷方式。
当真正的目标文件被删除之后，快捷方式也就没有存在的意义了。
在开发的过程中，对于同一个工具软件，可能要安装多个不同的版本，例如：Python2 和 Python3， JDK8 和 JDK9 等等。
此时就可以通过软链接来指定当前使用哪个版本。例如在我的电脑中：
$ ll -l /usr/bin/python*
lrwxrwxrwx 1 root root 9 12月 31 08:19 /usr/bin/python -> python2.7*
lrwxrwxrwx 1 root root 9 12月 31 08:19 /usr/bin/python2 -> python2.7*
-rwxr-xr-x 1 root root 3492624 3月 2 04:47 /usr/bin/python2.7*
lrwxrwxrwx 1 root root 9 12月 31 08:19 /usr/bin/python3 -> python3.5*
-rwxr-xr-x 2 root root 4456208 1月 27 02:48 /usr/bin/python3.5*
当在终端窗口中输入：python 时，启动的是 python2.7 版本。
如果有一天我需要使用 python3.5 版本，只需要把软链接 python 指向 python3.5 即可。
在 Linux 系统的动态库版本管理中，有一个 SONAME 的概念。
我们在编译一个动态链接库时，一般使用如下编译命令：
$ gcc -fPIC -shared -o libhello.so hello.c
在使用这个动态库时，需要链接这个库：-llibhello。
简单的 demo 可以这么来写，但是如果遇到一些比较大的项目，需要执行严格的版本管理，那应该怎么来操作呢？
Linux 系统已经为我们想到了问题的解决方案，利用 SO-NAME。
首先，在编译动态链接库文件时，就指定产生 SO-NAME，它会被存储在动态链接库 ELF 文件中。
我们来直接看一个优秀的开源工具 libevent 的例子：
$ ll /usr/lib/libevent-2.1.so*
lrwxrwxrwx 1 root root 17 Jul 27 2020 /usr/lib/libevent-2.1.so -> libevent-2.1.so.7
lrwxrwxrwx 1 root root 21 Jul 27 2020 /usr/lib/libevent-2.1.so.7 -> libevent-2.1.so.7.0.1
-rw-r--r-- 1 root root 412016 Jul 27 2020 /usr/lib/libevent-2.1.so.7.0.1
此时使用 readelf 命令来查看生成的动态库文件 libevent-2.1.so.7.0.1：
$ readelf -a libevent-2.1.so.7.0.1 | grep SONAME
0x000000000000000e (SONAME) Library soname: [libevent-2.1.so.7]
它这么做有什么好处呢？
Linux 系统在查找动态链接库文件时，会到下面这 3 个默认目录下查找(当然然还有其他目录，比如：当前目录，LD_LIBRARY_PATH 指定的目录)
/lib: 存放操作系统最关键和基础的库文件;
/usr/lib: 存放一些非系统运行时所需要的关键库文件;
/usr/local/lib: 存放用户自己安装的一些第三方库文件;
系统中安装的所有动态链接库，借助 ldconfig 这个程序，会自动的创建、更新或者删除对应的 SONAME(它是一个软链接，链接到 实际的库文件)，并把这些 SONAME 汇总到一个文件 /etc/ld.so.cache 中缓存起来。
这样，当动态库加载器查找动态库文件时，就可以直接在这个缓存文件中进行查找，加快了动态库的查找速度。
利用软链接的快捷方式功能就比较好理解了，想一想：我们为什么在 Windows 的桌面上创建很多软件的快捷方式啊？
在 Linux 中同样如此！
比如：最近一段时间的工作，每次都要打开一个路径很深的文件。
如果在资源管理器中，一层一层的点击鼠标，是不是比较浪费时间。
此时，就可以在桌面上创建一个软链接，每次直接双击就打开所链接的目标文件了。
比如我有一个文件夹，存储了10 个G的照片。
这些照片中的人物、拍照地点、拍照时间都是不一样的。
现在，我既想根据照片中的人物进行分类，也想根据拍照地点进行分类，还想根据拍照时间进行分类，那该怎么办？
因为一张照片可能同时属于多个不同的分类，难道每个分类中都复制一张照片？这样也太浪费硬盘空间了！
解决方案是：
所有的照片仍旧放在一个总的文件夹中，然后创建不同的分类文件夹，在每个分类文件夹中，创建硬链接到目标照片文件。
这样的话，不仅对照片进行了分类，而且一点都不占用硬盘空间。
当很多人同时对同一个文件进行维护的时候，如果大家都直接操作这个文件，万一不小心把文件删除了，大家就都玩完了！
此时，可以在每个人自己的私人目录中，创建一个硬链接。
每次只需要对这个硬链接文件进行操作，所有的改动会自动同步到目标文件中。
由于每个人都是操作硬链接文件，即使不小心删除了，也不会导致文件的丢失。
因为删除硬链接文件，仅仅是把该文件的 inode 节点中的 links 值减 1 而已，只要不为 0，就不会真正的删除文件。
一些小伙伴有定期备份文件、清理文件的好习惯。
在备份的时候，如果是实实在在的拷贝一份，那真的是太浪费磁盘空间，特别是对于我这种只有 256G 硬盘空间的笔记本。
此时，就可以利用硬链接功能，既实现文件备份的目的，又节省了大量的硬盘空间，一举两得！
很多备份工具利用的就是硬链接的功能，包括 git 工具，当克隆本地的一个仓库时，执行 clone 指令：
git clone --reference <repository>
git 并不会把仓库中的所有文件拷贝到本地，而仅仅是创建文件的硬链接，几乎是零拷贝！
来源整理于网络素材，版权归原作者所有，如有侵权，请联系删除，谢谢。
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ END ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 关注我的微信公众号，回复“加群”按规则加入技术交流群。
点击“阅读原文”查看更多分享，欢迎点分享、收藏、点赞、在看。
