最近我在求职面试时被问到这个问题.我是诚实的,并说我知道符号链接的行为以及如何创建一个,但不理解硬链接的使用以及它与符号链接的区别.
在文件系统下面的文件由inode表示(或者它是多个inode不确定)
文件系统中的文件基本上是指向inode的链接.
然后,硬链接只创建另一个文件,其中包含指向同一底层inode的链接.
删除文件时,它会删除一个指向底层inode的链接.只有在删除了所有指向inode的链接后,才会删除(或删除/可写入)inode.
符号链接是指向文件系统中另一个名称的链接.
一旦建立了硬链接,链接就是inode.删除重命名或移动原始文件不会影响硬链接,因为它链接到底层的inode.对inode数据的任何更改都会反映在引用该inode的所有文件中.
注意:硬链接仅在同一文件系统中有效.符号链接可以跨越文件系统,因为它们只是另一个文件的名称.
使用任何Linux(ish)控制台可能有所帮助的一些很好的直觉.
创建两个文件:
$ touch foo; touch bar
在其中输入一些数据:
$ echo "Cat" > foo $ echo "Dog" > bar
(实际上,我可以首先使用echo,因为它创建了文件,如果它们不存在......但不要介意.)
正如所料:
$cat foo; cat bar Cat Dog
让我们创建硬链接和软链接:
$ ln foo foo-hard $ ln -s bar bar-soft
让我们看看刚刚发生了什么:
$ ls -l foo foo-hard bar bar-soft -> bar
更改blah1的名称无关紧要:
$ mv foo foo-new $ cat foo-hard Cat
blah1-hard指向inode,文件的内容 - 没有改变.
$ mv bar bar-new $ ls bar-soft bar-soft $ cat bar-soft cat: bar-soft: No such file or directory
无法找到文件的内容,因为软链接指向已更改的名称,而不是内容.同样,如果blah1被删除,blah1-hard仍然保留内容; 如果删除blah2,则blah2-soft只是指向不存在的文件的链接.
俗话说,一张图片胜过千言万语.这是我如何想象它:
以下是我们如何获得该图片:
myfile.txt在文件系统中创建一个指向新inode的名称(包含文件的元数据,并指向包含其内容的数据块,即文本"Hello,World!":
$ echo 'Hello, World!' > myfile.txt
创建一个指向my-hard-link该文件的硬链接myfile.txt,这意味着"创建一个应指向指向同一inode的文件myfile.txt":
$ ln myfile.txt my-hard-link
创建指向my-soft-link该文件的软链接myfile.txt,这意味着"创建一个应指向该文件的文件myfile.txt":
$ ln -s myfile.txt my-soft-link
看看如果myfile.txt删除(或移动)将会发生什么:my-hard-link仍然指向相同的内容,因此不受影响,而my-soft-link现在指向什么都没有.其他答案讨论每个人的利弊.
当原始文件被移动时,硬链接很有用.例如,将文件从/ bin移动到/ usr/bin或移动到/ usr/local/bin.这个文件在/ bin中的任何符号链接都会被破坏,但是硬链接(直接指向文件的inode的链接)并不关心.
硬链接可能占用较少的磁盘空间,因为它们只占用目录条目,而符号链接需要它自己的inode来存储它指向的名称.
硬链接也需要较少的时间来解决 - 符号链接可以指向符号链接目录中的其他符号链接.其中一些可能在NFS或其他高延迟文件系统上,因此可能导致网络流量得到解决.始终在同一文件系统上的硬链接总是在一次查找中解决,并且从不涉及网络延迟(如果它是NFS文件系统上的硬链接,NFS服务器将执行解析,并且它将不可见客户系统).有时这很重要.不适合我,但我可以想象这可能很重要的高性能系统.
我还认为像mmap(2)甚至open(2)这样的东西使用与硬链接相同的功能来保持文件的inode活动,这样即使文件被取消链接(2),inode仍然允许进程继续访问,只有在进程关闭后,文件才会真正消失.这允许更安全的临时文件(如果你可以原子地进行打开和取消链接,可能有一个我不记得的POSIX API,那么你真的有一个安全的临时文件)你可以读/写没有任何人能够访问您的数据.好吧,在/ proc让每个人都能够查看你的文件描述符之前,这是真的,但这是另一个故事.
说到这一点,恢复在进程A中打开但在文件系统上取消链接的文件围绕使用硬链接重新创建inode链接,这样当打开它的进程关闭或消失时,文件不会消失.
查看硬链接和符号链接之间差异的简单方法是通过一个简单的示例.指向文件的硬链接将指向存储文件的位置或该文件的inode.符号链接将指向实际文件本身.
因此,如果我们有一个名为"a"的文件并创建一个硬链接"b"和一个符号链接"c",它们都引用文件"a":
echo "111" > a ln a b ln -s a c
"a","b"和"c"的输出将是:
cat a --> 111 cat b --> 111 cat c --> 111
现在让我们删除文件"a",看看"a","b"和"c"的输出会发生什么:
rm a cat a --> No such file or directory cat b --> 111 cat c --> No such file or directory
所以发生了什么事？
因为文件"c"指向文件"a"本身,如果删除文件"a",则文件"c"将没有任何指向,实际上它也被删除.
但是,文件"b"指向文件"a"的存储位置或inode.因此,如果文件"a"被删除,那么它将不再指向inode,但由于文件"b",因此inode将继续存储属于"a"的任何内容,直到不再有硬链接指向它为止.
软链接:
软或符号更像是对原始文件的快捷方式....如果删除原始文件,则快捷方式会失败,如果只删除快捷方式,则原始文件不会发生任何变化.
软链接语法:ln -s Pathof_Target_file link
输出: link -> ./Target_file
证明: readlink link
同样在ls -l link输出中,您将看到lrwxrwxrwx作为l的第一个字母,表示该文件是软链接.
删除链接: unlink link
注意:如果您愿意,即使将软链接从当前目录移动到其他位置,您的软链接也可以正常工作.确保在创建软链接时给出绝对路径而不是相对路径.ie(从/ root/user/Target_file开始而不是./Target_file)
硬链接:
硬链接更多是镜像副本或同一文件的多个路径.对file1执行某些操作并将其显示在文件2中.删除一个仍然保持另一个正常.
仅当删除了所有(硬)链接或(同一文件)inode的所有路径时,才会删除inode(或文件).
一旦建立了硬链接,该链接就具有原始文件的inode.删除重命名或移动原始文件不会影响硬链接,因为它链接到底层的inode.对inode数据的任何更改都会反映在引用该inode的所有文件中.
硬链接语法:ln Target_file link
输出:将使用与Targetfile相同的inode编号创建具有名称链接的文件.
证明:( ls -i link Target_file 检查他们的inode)
删除链接:( rm -f link删除链接就像普通文件一样)
注意:符号链接可以跨越文件系统,因为它们只是另一个文件的名称.而硬链接仅在同一文件系统中有效.
符号链接有一些功能缺少硬链接:
硬链接指向文件内容.而软链接指向文件名.
而硬链接的大小是内容的大小,而软链接具有文件名大小.
硬链接共享相同的inode.软链接没有.
硬链接无法跨文件系统.软链接.
你知道符号链接指向硬链接的位置,你需要浏览整个文件系统来查找共享相同inode的文件.
# find / -inum 517333
/home/bobbin/sync.sh /root/synchro
硬链接不能指向目录.
硬链接有两个限制:
目录不能硬链接.Linux不允许这样做来维护目录的非循环树结构.
无法跨文件系统创建硬链接.这两个文件必须位于相同的文件系统上,因为不同的文件系统具有不同的独立inode表(不同文件系统上的两个文件,但具有相同的inode编号将不同).
符号链接链接到路径名称.这可以是系统文件树中的任何位置,甚至在创建链接时也不必存在.目标路径可以是相对路径或绝对路径.
硬链接是指向inode的附加指针,这意味着它们只能存在于与目标相同的卷上.文件的其他硬链接与用于引用文件的"原始"名称无法区分.
我会指向维基百科:
符号链接
硬链接
几点:
与硬链接不同,符号链接可以跨文件系统(大多数情况下).
符号链接可以指向目录.
硬链接指向文件,使您能够引用具有多个名称的同一文件.
只要至少有一个链接,数据仍然可用.
执行增量备份时,硬链接非常有用.例如,请参阅rsnapshot.我的想法是使用硬链接进行复制:
将备份号码n复制到n + 1
将备份n - 1复制到n
...
将备份0复制到备份1
使用任何更改的文件更新备份0.
除了您所做的任何更改之外,新备份不会占用任何额外空间,因为所有增量备份都将指向未更改的文件的同一组inode.
我补充说尼克的问题:什么时候硬链接有用还是必要？我想到的唯一一个符号链接无法完成工作的应用程序是在chrooted环境中提供系统文件的副本.
硬链接与软链接可以通过此图像轻松解释。
京公网安备 11010802040832号 | 京ICP备19059560号-6 