Shulou(Shulou.com)06/01 Report--

This article mainly introduces "what is the link file under Linux". In the daily operation, I believe that many people have doubts about what the link file under Linux is. The editor consulted all kinds of information and sorted out a simple and easy-to-use method of operation. I hope it will be helpful to answer the question of "what is the link file under Linux?" Next, please follow the editor to study!

Several basic concepts

Linked files under Linux can be divided into hard links (hard link) and soft links (soft link). To understand them, you must first understand several basic concepts.

Inode

In addition to the pure data itself, the file must also contain the management information of the pure data, such as the file name, access rights, the owner of the file and the disk block corresponding to the data of the file, and so on. These management information is called mata data and is stored in the inode node of the file. We can view the inode information of a file through the stat command:

$stat / etc/passwd File: "/ etc/passwd" Size: 936 Blocks: 8 IO Block: 4096 Common documents Device: fd00h/64768d Inode: 137143 Links: 1Access: (0644 root) Uid: (0 / root) Gid: (0 / root) Access: 2016-08-05 23V 0V 39.9059995 + 0800Modify: 2016-07-15 16:36

Here we look at the metadata information in the / etc/passwd file. The ls-l command also lists some file metadata information (from left to right: permissions, number of hard links, ownership, group, file size, last changed time, file name), but the stat command outputs more complete information. We notice that in the stat output, the file has three timestamps: recent access, recent changes, and recent changes, corresponding to Access, Modify, and Change in English. Access time is easy to understand, and every time you access the data in this file (note, it's not metadata), this time is updated. For example, when you read the contents of a file with the cat or more command, the access time is updated, while with the ls or stat command, the access time value is not updated because you only access the inode of the file. Modify time is the last time the file data was modified, for example, when the file was edited with vim and saved, the file modify time is updated. Change time is the last time the file metadata (that is, inode) is modified, for example, when the owner of the file is modified with the chown command, the change time of the file is updated.

In fact, when we first created the partition and created the text system with commands such as mkfs.ext4, we already retained the inode node area in the fixed area of the file system. We can view the size and usage of the inode node area of a file system through the df-I command:

# df-ih / dev/mapper/pdc_bcfaffjfaj2 file system Inode used (I) available (I) used (I)% mount point / dev/mapper/pdc_bcfaffjfaj2 18m 127K 18M1 / home

As you can see, in the author's Linux Mint17.3 system, the partition / dev/mapper/pdc_bcfaffjfaj2 retains a total of 18m inode area, which has been used at 127K. Is it possible that there is still space in a partition and the inode area has been used up? Yes, there is. This happens when there are a lot of small files! At this point, even though there is still space available in the file system, we still cannot continue to create new files in this file system. What if there are really a lot of small files in my application environment? In fact, when we set up the ext4 file system, we can manually specify the proportion of the inode area. We can man mkfs.ext4 to view the relevant parameters and options, which will not be detailed here.

When we just looked at the inode information of the file with stat, we saw a line of Inode: 137143 in the output, which is the inode number of the / etc/passwd file. Each inode has a unique inode number for the entire file system, and the operating system kernel identifies different files by the inode number rather than the file name. The filename is just for the convenience of the user. The kernel finds the inode through the filename and accesses the actual file data through inode. Is it possible that multiple file names correspond to the same inode? Yes, this gives rise to the so-called hard link file.

Dentry

Although each file corresponds to a unique inode number, the inode number is messy and meaningless, regardless of user memory and use, we want to take a meaningful file name for each file. One of the basic functions provided by modern file systems is to access by name, so we also need to establish a correspondence between file names and inode numbers, which leads to the concept of directory entries (directory entry, that is, dentry). In the Linux file system, there is a special kind of file called "directory", and the directory stores the corresponding relationship between the file name of all the files under that directory and the inode number, where each corresponding relationship is called a dentry. Linux builds all files and directories into an upside-down tree structure, so that as long as we determine the inode number of the root directory, we can access the entire file system by name.

Hard link

The essence of hard links is another entry for existing files in the directory tree. In other words, the hard link and the original file are dentry that live in different or the same directory. They point to the same inode, corresponding to the same disk data block (data block), and have the same access rights, attributes, and so on. In short, a hard link is an alias for an existing file.

The advantage of hard links is that they take up little disk space (because only one directory item has been added), but this advantage is not obvious compared to soft links (because soft links also take up very little disk space). In addition, hard links have the following limitations: 1. Hard links cannot be created across file systems. The reason is simple: the inode number is guaranteed to be unique only within a file system, and the inode number can be duplicated if it spans the file system. 2. You cannot create hard links to directories. I will explain the reason later. Because of these limitations of hard links and the fact that soft links are easier to manage, soft links are more commonly used. As can be seen from the examples given in this article, there are almost all examples of soft links.

Soft link

Soft links, also known as symbolic links (symbolic link), are abbreviated to "symlink". Unlike a hard link, which is just a directory entry, a soft link is a file itself, but the content of this file is a pointer to another file name. When Linux accesses the soft link, it follows the pointer to find the target file that contains the actual data. We also take books as an example. A soft link is a chapter in a book, but there is nothing in this chapter, only a line of words "turn to a certain chapter and page".

A soft link can point to a file of another partition across a file system, to a file of a remote host across a host, or to a directory. In the list of files output by ls-l, the "l" character in the first field indicates that the file is a symbolic link.

$ls-ltotal 0lrwxrwxrwx 1 wjm wjm 11 Aug 10 00:51 hh-> / etc/passwd

We see that the permission of the soft link is 777, that is, all permissions are open, in fact, you can not use the chmod command to modify its permissions, but the actual file protection permissions still work.

In addition, a symbolic link can point to a file that does not exist (it may be that the file that was originally pointed to has been deleted, or the file system that it points to has not been mounted, or it points to a file that does not exist when the symbolic link is first established, etc.), we call this state "broken". In contrast, hard links cannot point to a file that does not exist.

What are the benefits of using links?

Here we summarize the following benefits of using linked files:

Maintain software compatibility

For example, in RHEL6, we look at the output of the following command:

$ls-l / bin/shlrwxrwxrwx. 1 root root 4 Jul 15 11:41 / bin/sh-> bash

We can see that the / bin/sh file is actually a symbolic link to / bin/bash. Why is it designed like this? Because the first line of almost all shell script looks like this:

#! / bin/sh

"#!" The symbol indicates that the line specifies the interpreter used by the script. #! / bin/sh means to use Bourne Shell as the interpreter, which is an early Shell. To run the script smoothly without having to modify shell script, we just need to create a soft link / bin/sh to point to / bin/bash. In this way, you can let bash interpret the script originally written for Bourne Shell.

Facilitate the use of software

For example, we installed a large software Matlab, it may be installed by default in the / usr/opt/Matlab directory, its executable file location in the / usr/opt/Matlab/bin directory, unless you add in this path to the PATH environment variable, otherwise every time you run the software you need to enter a long list of paths is very inconvenient. You can also do this:

$ln-s / usr/opt/Matlab/bin/matlab ~ / bin/matlab

By creating a symbolic link under your ~ / bin (the bin system is already included in the PATH environment variable by default), you don't need to enter the full path on the command line in the future, just type matlab.

Maintain the old operating habits

For example, in SuSE, the location of the startup script is in the / etc/init.d directory, while in the RedHat distribution, it is in the / etc/init.d/rc.d directory. To avoid the situation where the administrator can't find the location due to the conversion from SuSE to RedHat system, we can create a symbolic link / etc/init.d to point to / etc/init.d/rc.d. In fact, that's exactly what the RedHat distribution does:

$ls-ld / etc/init.d/lrwxrwxrwx. 1 root root 11 Jul 15 11:41 init.d-> rc.d/init.d

Facilitate system management

One of the most impressive examples should be the symbolic links in the / etc/rc.d/rcX.d directory (X is the number 0x7).

$ls-l / etc/rc.d/total 60drwxr-xr-x. 2 root root 4096 Jul 15 16:36 init.d-rwxr-xr-x. 1 root root 2617 Nov 23 2013 rcdrwxr-xr-x. 2 root root 4096 Jul 15 16:36 rc0.ddrwxr-xr-x. 2 root root 4096 Jul 15 16:36 rc1.ddrwxr-xr-x. 2 root root 4096 Jul 15 16:36 rc2.ddrwxr-xr-x. 2 root root 4096 Jul 15 16:36 rc3.ddrwxr-xr-x. 2 root root 4096 Jul 15 16:36 rc4.ddrwxr-xr-x. 2 root root 4096 Jul 15 16:36 rc5.ddrwxr-xr-x. 2 root root 4096 Jul 15 16:36 rc6.d-rwxr-xr-x. 1 root root 220 Nov 23 2013 rc.local-rwxr-xr-x. 1 root root 19688 Nov 23 2013 rc.sysinit

There are many scripts in the init.d/ directory to start and stop system services, such as sshd, crond, and so on. These scripts can accept a parameter that means to start (start) or stop (stop) the service. To determine which scripts to run at a run level and which parameters are passed to those scripts, RedHat designs an additional directory mechanism, namely seven directories from rc0.d to rc6.d, each corresponding to a run level. If you need to start a service or stop a service at a certain run level, establish a symbolic link in the corresponding rcX.d directory to point to the script in the init.d/ directory. Such as:

$ls-l / etc/rc.d/rc3.dtotal 0lrwxrwxrwx. 1 root root 19 Jul 15 11:42 K10saslauthd->.. / init.d/saslauthdlrwxrwxrwx. 1 root root 20 Jul 15 11:42 K50netconsole->.. / init.d/netconsolelrwxrwxrwx. 1 root root 21 Jul 15 11:42 K87restorecond->.. / init.d/restorecondlrwxrwxrwx. 1 root root 15 Jul 15 11:42 K89rdisc->.. / init.d/rdisclrwxrwxrwx. 1 root root 22 Jul 15 11:44 S02lvm2-monitor->.. / init.d/lvm2-monitorlrwxrwxrwx. 1 root root 19 Jul 15 11:42 S08ip6tables->.. / init.d/ip6tableslrwxrwxrwx. 1 root root 18 Jul 15 11:42 S08iptables->.. / init.d/iptableslrwxrwxrwx. 1 root root 17 Jul 15 11:42 S10network->.. / init.d/networklrwxrwxrwx. 1 root root 16 Jul 15 11:44 S11auditd->.. / init.d/auditdlrwxrwxrwx. 1 root root 17 Jul 15 11:42 S12rsyslog->.. / init.d/rsyslog... ....

The service scripts that need to be run under runlevel 3 and the corresponding parameters are listed here, where the first letter S and K of the symbolic link denote the passing parameters start and stop, respectively, followed by two digits indicating the sequence in which the script is run. In this way, you can control which service scripts each runlevel needs to run as long as you add or remove links in the rcX.d directory; and if you need to modify a service script, you only need to edit the files in the init.d/ directory ("real"), and it can affect the soft links ("splitter") in all rcX.d directories. What a simple and ingenious design it is!

At this point, the study of "what is the link file under Linux" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.