侵权投诉

订阅
纠错
加入自媒体

Linux中的索引节点、软链接、硬链接是什么?应该怎么应用?

2021-06-18 15:26
道哥分享
关注

最近,看到很多文章都在介绍 Linux 中的文件系统,其中就包括:inode 节点、软链接、硬链接等重要的概念。

于是就有小伙伴私信问我:这些概念我都懂,但是我能利用他们来完成什么工作呢?

或者说,在哪些情况下,软链接和硬链接能够提供提供更好的解决方案呢?

这篇文章我们就来简单梳理一下,软链接和硬链接的几个使用场景。

什么是索引节点
什么是硬链接
什么是软链接

软链接应用之:灵活切换不同版本的目标程序
软链接应用之:动态库版本管理
软链接应用之:快捷方式

硬链接之应用:从不同角度对文件进行分类
硬链接应用之:文件多人共享
硬链接之应用:文件备份

文件和索引节点 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 并不会把仓库中的所有文件拷贝到本地,而仅仅是创建文件的硬链接,几乎是零拷贝!

声明: 本文由入驻维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。

发表评论

0条评论,0人参与

请输入评论内容...

请输入评论/评论长度6~500个字

您提交的评论过于频繁,请输入验证码继续

暂无评论

暂无评论

技术文库

电子工程 猎头职位 更多
文章纠错
x
*文字标题:
*纠错内容:
联系邮箱:
*验 证 码:

粤公网安备 44030502002758号