标签:
当几个用户同在一个项目里工作时,常常需要共享文件。如果一个共享文件同时出现在属于不同用户的不同目录下,工作起来就很方便。例如B和C目录下有一文件D是两者都可以访问和修改的共享文件,这样是很方便,但也会有一些问题,如果目录中包含磁盘地址,则当连接文件时,必须把C目录中的磁盘地址复制到B目录中,如果B或C随后又往该文件中添加内容,则新的数据块将只列入进行添加工作的用户的目录中。其他的用户对此改变是不知道的,违背了共享的目的。两种方法解决这种问题。
透过文件系统的inode 连结来产生新档名,而不是产生新档案!这种又称 为实体链接 (hardlink).
· 每个档案都会占用一个inode ,档案内容由 inode的记录来指向;
· 想要读取该档案,必项要经过目录记录的文件名来指向到正确的inode 号码才能读取。 也就是说,其实文件名只与目录有关,但是档案内容则与 inode 有关。那举想一想, 有没有可能有多个档名对应到同一个 inode 号码呢?有的!那就是 hard link 的由来。 所以简单的说:hard link 只是在某个目录下新增一笔档名链接到某 inode 号码的关连记彔而已。
[
举个例子来说,假设我系统有个 /root/crontab 他是 /etc/crontab 的实体链接,也就是说这两个档名 连结到同一个 inode ,自然这两个文件名的所有相关信息都会一模一样(除了文件名之外)。实际的情况可以如下所示:
你可以发现两个档名都连结到 1912701 这个 inode 号码,所以您瞧瞧,是否档案的权限/属性完全一 样呢? 因为这两个『档名』其实是一模一样的『档案』啦!而且你也会发现第二个字段由原本的 1 发 成 2 了! 那个字段称为『连结』,这个字段的意义为:『 有多少个档名链接到这个 inode 号码』的意思。 如果将读取到正确数据的方式画成示意图,就类似如下画面:
你可以透过 1 或 2 的目录的 inode 指定的block 找到两个不同的档名,而不管使用哪 个档名均可以指到 real 那个 inode 去读取到最终数据!那这样有好处呢?最大的好处就是『安 全』!如同上图中, 如果你将任何一个『档名』删除,其实 inode 与 block 都还是存在的! 此时你可以透过另一个『档名』来读取到正确的档案数据喔!此外,不论你使用哪个『档名』来编辑,最终的结果都会写入到相同的 inode 与block 中,因此均能进行数据的修改!解决了上述的问题,一般来说,使用 hard link 设定链接文件时,磁盘的空间与 inode 的数目都不会改发!我们还是由图 2.2.1 来看,由图中可以知道, hard link 只是在某个目录下的 block 多写入一个关连数据而已,既不会增加 inode 也不会耗用 block 数量。
Tips:
简单来讲:硬链接就是同一文件使用了多个别名(有共同的inode),是不同的文件指向相同的inode。达到文件共享的目的;
优点:安全,修改同步,删除一个硬链接文件并不影响其他有相同inode号的文件;
缺点:不能跨 Filesystem,不能 link 目录。
不能跨Filesystem:由图 2.2.1 其实我们也能够知道,事实上 hard link 应该仅能在单一文件系统中进行的,应该是不能够跨文件系统才对! 因为图 2.2.1 就是在同一个 filesystem 上嘛!所以 hard link 是有限制的;
不能link目录:因为如果使用 hard link 链接到目彔时, 链接癿数据需要连同被链接目彔底下的所有数据都建立链接,举例来说,如果你要将 /etc 使用实体链接建立一个 /etc_hd 的目彔时,那举在 /etc_hd 底下的所有档名同时都与/etc 底下的檔名要建立 hard link 的,而不是仅连结到 /etc_hd 与/etc 而已。 并且,未来如果需要在 /etc_hd 底下简历新档案时,连带的/etc底下的数据又得要建立一次hard link,因此造成环境相当大的复杂度。所以不能link目录。
hard link 的制作中,其实还是可能会改发系统的block,那就是当你新增这笔数
据却刚好将目录的block 填满时,就可能会新加一个block 来记录文件名关连性,
而寻致磁盘空间的变化!不过,一般 hard link 所用掉的关连数据量很小,所以通常
不会改发 inode 与磁盘空间的大小喔
相对于hard link , Symbolic link 可就好理解多了,基本上, Symbolic link 就是在建立一个独立的档案,而这个档案会让数据 的读取指向他link的那个档案的档名!由与只是利用档案来做为指向的动作, 所以,当来源档被删除之后,symboliclink 的档案会『开不了』 , 会一直说『无法开启某档案!』。实际上就是找不到原始『档名』而已啦! 举例来说,我们先建立一个符号链接文件链接到 /etc/crontab 去看看:
我们可以知道两个档案指向不同的iode 号码,当然就是两个独立的档案存在! 而且连结档的重要内容就是他会写上目标档案的『文件名』 , 你可以发现为什么上表中连结档的大小为 12 bytes 呢? 因为箭头(-->)右边的档名『 /etc/crontab』总共有 12 个英文,每个英文占用 1 个 byes , 所以档案大小就是12bytes 了! 关于上述的说明,我们以如下图示来解释:
由 1 号 inode 读取到连结档的内容仅有档名,根据档名链接到正确的目彔去取得目标档案的inode , 最终就能够读取到正确的数据了。你可以发现的是,如果目标档案(/etc/crontab)被删除了,那整个环节就会无法继续进行下去,所以就会产生无法透过连结档读取的问题了! 这里还是得特别留意,这个 Symbolic Link 与 Windows 的快捷方式可以给他划上等号,由 Symbolic link 所建立的档案为一个独立的新的档案,所以会占用掉 inode 与 block 喔! 由上面的说明来看,似乎 hard link 比较安全,因为即使某一个目彔下的关连数据被杀掉了, 也没有关系,只要有任何一个目彔下存在着关连数据,那举该档案就不会不见!举上面的例子来说,我的 /etc/crontab 与 /root/crontab 指向同一个档案,如果我删除了 /etc/crontab 这个档案,该删除的动作其实只是将 /etc 目彔下关于crontab 的关连数据拿掉而已, crontab 所在的 inode 与 block 其实都没有变动。
软链接:文件用户数据中有效的内容是另一文件的路径名的指向,是一普通文件,数据块有点特殊。删除软链接不影响源文件。
优点:方便,可以用到目录。只要简单地提供一个机器的网络地址以及文件在该机器上驻留的路径,就可以连接全球任何地方机器上的文件。
缺点:需要额外的开销。必须读取包含路径的文件,然后要一个部分一个部分的扫描路径,直到找到inode节点,也需要额外的磁盘存取。删除源文件,链接文件为死文件。
因为硬链接应用受到限制,软链接应用较为广泛。
版权声明:本文为博主原创文章,未经博主允许不得转载。
标签:
原文地址:http://blog.csdn.net/sinat_24520925/article/details/47722319