unx35.htm

Linux Unix揭密.高质量电子书籍.对学习Linux有大帮助,欢迎下载学习.

<BR>

<BR></LI>

<LI><B>Link (Hard Link).</B> A link is the name given to a directory entry. It links the directory entry to the inode that describes the actual item (file, device, and so on). This physical linking is a map directly to the inode, and the inode describes 
space on this file system. Thus, the link can be a file only on this file system. Each file has one or more links. (When a file is removed from a directory, the link count is decremented. When it reaches zero, the inode and the disk space it points to are 

freed, causing the data to be deleted.) The number of links to a given inode is shown in the ls -l output.

<BR>

<BR></LI></UL>

<P>I created a directory, t, and made three empty directories underneath it to show how UNIX makes use of links to tie the file system hierarchy together. The empty directories are a, b, and c. Here is an ls -liR output of the tree, starting at t:

<BR></P>

<PRE>total 40

   23 drwxr-xr-x   5 syd      users    91 Feb 26 10:18 .

    2 drwxrwxrwx   5 root     root    408 Feb 26 10:18 ..

   27 drwxr-xr-x   2 syd      users    37 Feb 26 10:18 a

   31 drwxr-xr-x   2 syd      users    37 Feb 26 10:18 b

   33 drwxr-xr-x   2 syd      users    37 Feb 26 10:18 c

./a:

total 16

   27 drwxr-xr-x   2 syd      users    37 Feb 26 10:18 .

   23 drwxr-xr-x   5 syd      users    91 Feb 26 10:18 ..

./b:

total 16

   31 drwxr-xr-x   2 syd      users    37 Feb 26 10:18 .

   23 drwxr-xr-x   5 syd      users    91 Feb 26 10:18 ..

./c:

total 16

   33 drwxr-xr-x   2 syd      users    37 Feb 26 10:18 .

   23 drwxr-xr-x   5 syd      users    91 Feb 26 10:18 ..</PRE>

<P>The first number on each line is the inode number, followed by the permission mask. The next number is the hard link count. This is the number of times that this inode appears in a directory entry. The last column is the filename (remember, directories 

are just files with special characteristics). The file . is the current directory, which is pointed to by inode 23. The file .. is the parent of this directory, and for the directory t, it is inode 2, the root of this file system. Notice how in directories 

a, b, and c, the .. entries are also inode 23. By mapping the name .. to the same inode as the parent directory, UNIX has built the reverse link in the file system. This listing shows four entries with the inode number 23, yet the link count on each is 5. 

The fifth link is the entry in the root directory for t, this directory itself.

<BR></P>

<PRE>23 drwxr-xr-x   5 syd      users       91 Feb 26 10:18 t</PRE>

<UL>

<LI><B>Symlink (Soft Link).</B> A symlink or symbolic link is a file whose contents are treated as a pathname. This pathname is used whenever the symlink is referenced. Because it is just a pathname (relative or absolute), it can cross file system 
boundaries. Unlike links, creating a symlink does not require the existence of the file it points to, and removing the symlink does not remove the file. It is merely a pointer to the file to be used whenever this symlink is referenced.

<BR>

<BR></LI></UL>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> Symbolic links were developed in the Berkeley derivatives of UNIX. They are available on any derivative of the Berkeley fast file system, such as ufs file systems. They are not available on the older 

UNIX s5 type file system.

<BR></NOTE>

<HR ALIGN=CENTER>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP:</B> Because symbolic links can point anywhere, they are a wonderful tool to remap directories to other file systems when space is a problem, or to make multiple links into the same directory (something UNIX 

does not allow with hard links because it would mess up the meaning of ..). Just move the files to the new file system, then create a symlink in the old directory pointing to the new location. It will cause a problem, however, in traversing back up the 
chain using .. unless the shell you use is aware of symlinks and compensates for the problem. The Korn Shell under SVR4 does handle this correctly.

<BR></NOTE>

<HR ALIGN=CENTER>

<UL>

<LI><B>Mount Point.</B> This is the directory entry in the file system hierarchy where the root directory of a different file system is overlaid over the directory entry. UNIX keeps track of mount points and accesses the root directory of the mounted file 

system instead of the underlying directory. A file system can be mounted at any point in the hierarchy, and any type of file system can be mounted&#151;it doesn't have to be the same type as its parent.

<BR>

<BR></LI></UL>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="caution.gif" WIDTH = 37 HEIGHT = 35><B>CAUTION: </B>Because the new file system is mounted on top of a directory of its parent, its parent must be mounted first. Also, this hides the underlying directory entry and any contents it had. See the 
section titled &quot;Mounting File Systems&quot; later in this chapter.

<BR></NOTE>

<HR ALIGN=CENTER>

<UL>

<LI><B>Inode.</B> This is the building block of the UNIX file system. Each file system contains an array of inodes. They contain a complete description of the directory entry, including the following:

<BR>

<BR>mode Permission mask and type of file. The bit mask in this field defines whether the file is an ordinary file, directory, device, symlink, or other special type of entry. It also describes the permissions. This is the field that is decoded into the 
drwxr-xr-x string by the ls command.

<BR>

<BR>link count The number of links to this file (the number of directories that contain an entry with this inode number).

<BR>

<BR>user ID User ID of the owner of the file.

<BR>

<BR>group ID Group ID of the owner of the file, used to map the group access permissions in mode.

<BR>

<BR>size Number of bytes in the file.

<BR>

<BR>access time Time (in UNIX time format) that the file was last accessed.

<BR>

<BR>mod time Time (in UNIX time format) that the file was last modified.

<BR>

<BR>inode time Time (in UNIX time format) that the inode entry was last modified. This does not include changes to the size or time fields.

<BR>

<BR>block list A list of the disk block numbers of the first few blocks in the file. Only the first few (10&#151;12, it varies depending on file system type) are kept directly in the inode.

<BR>

<BR>indirect list A list of the disk block numbers holding the single, double, and triple indirect blocks.

<BR>

<BR>

<BR></LI></UL>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> A trade-off of size versus speed was made in the design of the original UNIX file system; it was effective and has remained. Most files in UNIX are small. By placing only the first 10&#151;12 block 
numbers in the inode, the space used by the inode table can be kept small. Yet for normal files that are small (less than 96 KB on ufs file systems), all of the block numbers are immediately accessible in the inode. For larger files, a disk block is used 
to hold a list of block numbers. This is called the single indirect block. Still larger files use a block containing a list of blocks containing the block numbers or a double indirect block. The largest files can use triple indirect blocks. (See Figure 
35.1.) The largest file that can be described is a ufs file system with

<P>

<BR><B><A HREF="35unx01.gif">Figure 35.1. </B><B><I>ufs</I></B><B> disk allocation block layout.</A></B>

<BR></P>

<TABLE BORDER>

<TR>

<TD>

<P>no indirects</P>

<TD>

<P>12<B>&#180;</B>8192 = 96 KB or 98,304 bytes</P>

<TR>

<TD>

<P>only single</P>

<TD>

<P>no indirect + 2048<B>&#180;</B>8192 = 16,480 KB or 16,875,520 bytes</P>

<TR>

<TD>

<P>only double</P>

<TD>

<P>single indirect + 2048<B>&#180;</B>2048<B>&#180;</B>8192 = 32,784 MB or 34,376,613,888 bytes</P>

<TR>

<TD>

<P>with triple</P>

<TD>

<P>double indirect + 2048<B>&#180;</B>2048<B>&#180;</B>2048<B>&#180;</B>8192 = 67,141,648 MB or 70,403,120,791,552 bytes (if you could find a disk that large)</P></TABLE>

<BR>

In UNIX, the inode, not the directory entry, contains all the information about the file. The only information in the directory is the filename and its inode number. This indirection from the filename to inode entry is what allows for links.

<BR></NOTE>

<HR ALIGN=CENTER>

<UL>

<LI><B>Super-block.</B> The controlling block of a file system. It contains the information about the file system and the heads of several lists, including the inode list, the free inode list, and the free block list. This block is cached in memory for all 

mounted file systems and is periodically also written to the disk.

<BR>

<BR></LI></UL>

<H4 ALIGN="CENTER">

<CENTER><A ID="I7" NAME="I7">

<FONT SIZE=3><B>The System V Release 4 File System Layout</B>

<BR></FONT></A></CENTER></H4>

<P>As installed in Chapter 33, the files in a UNIX installation are split into several file systems. One typical layout is shown in Figure 35.2.

<BR></P>

<P>

<BR><B><A HREF="35unx02.gif">Figure 35.2. Typical UNIX System V Release 4 file </B><B>system layout.</A></B>

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP:</B> Note that in Figure 35.2, the file systems have been split across the two disks in an attempt to allow for parallel access to the file systems. Files are accessed from usr and opt quite often. Files are 

written to var and home frequently. These are split across the two disk drives.

<BR></NOTE>

<HR ALIGN=CENTER>

<H3 ALIGN="CENTER">

<CENTER><A ID="I8" NAME="I8">

<FONT SIZE=4><B>Formatting a Disk</B>

<BR></FONT></A></CENTER></H3>

<P>Adding a disk to a UNIX system requires the following three steps:

<BR></P>

<UL>

<LI>Low level formatting&#151;Writing the sector addresses to the disk

<BR>

<BR></LI>

<LI>Labeling&#151;Writing the slice information to the disk

<BR>

<BR></LI>

<LI>Making file systems&#151;Writing the file system header information to a slice

<BR>

<BR></LI></UL>

<P>The first two are covered in this section and making file systems is covered in the next section.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I9" NAME="I9">

<FONT SIZE=3><B>Low-Level Format</B>

<BR></FONT></A></CENTER></H4>

<P>Before any operating system can use a disk, it must be initialized. This low-level format writes the head, track, and sector numbers in a sector preamble and a checksum in the postamble to every sector on the disk. At the same time, any sectors that are 

unusable due to flaws in the disk surface are so marked and, depending on the disk format, an alternate sector might be mapped in place to replace the flawed sector.

<BR></P>

<P>Low-level disk formatting is performed differently for the three types of disk drives used by UNIX systems.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I10" NAME="I10">

<FONT SIZE=3><B>Formatting ESDI, MFM, or SMD Drives</B>

<BR></FONT></A></CENTER></H5>

<P>UNIX cannot format these drives while it is running. Instead, a stand-alone format program is used. It is usually provided by the manufacturer of the computer or the disk controller board. On PC hardware, this formatter runs either in 'Debug' mode 
(before the operating system is loaded) or as an MS-DOS utility. Follow the manufacturer's directions for formatting these drives and be sure to have the drive mark the flawed sectors into the flaw map. UNIX will make use of this flaw map when creating its 

alternate track list.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP:</B> All three of these disk types are obsolete and slow. UNIX performance is very dependent on disk access times and transfer rate. It would be best to consider replacing these disks as soon as practical 
with SCSI disks.

<BR></NOTE>

<HR ALIGN=CENTER>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="caution.gif" WIDTH = 37 HEIGHT = 35><B>CAUTION: </B>When adding this disk to your UNIX system, UNIX will insist on scanning the disk for flawed sectors, destroying any information on the disk. It needs to do this because UNIX file systems expect 

the disk to be flawless. The operating system or the disk drive itself is expected to map out bad sectors. For performance reasons, it often flaws entire tracks when any sector is bad. This can cause the actual disk space to be less than the drive 
indicates.

<BR></NOTE>

<HR ALIGN=CENTER>

<H5 ALIGN="CENTER">

<CENTER><A ID="I11" NAME="I11">

<FONT SIZE=3><B>IDE</B>

<BR></FONT></A></CENTER></H5>

<P>These drives are found on PC systems and extend the PC's ISA bus directly into the disk drive. They were designed to reduce the cost of MS-DOS PCs, and they come preformatted from the factory. Most format utilities are unable to low-level format these 
drives.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="caution.gif" WIDTH = 37 HEIGHT = 35><B>CAUTION: </B>Do not attempt to format an IDE drive without a specialized format utility approved for the specific IDE drive you are using. Normally there is no need to low-level format these drives, because 

they come from the factory preformatted.

<BR></NOTE>

<HR ALIGN=CENTER>

<H5 ALIGN="CENTER">

<CENTER><A ID="I12" NAME="I12">

<FONT SIZE=3><B>SCSI</B>

<BR></FONT></A></CENTER></H5>

<P>Most current UNIX systems are designed for SCSI disks. These disks come preformatted from the factory and normally do not need to be reformatted in the field. They also handle bad sector remapping internally. There is no reason to scan these disks for 
flawed sectors.

<BR></P>

<P>If you do need to reformat these disks, you generally have three options:

<BR></P>

<UL>

<LI>Use the UNIX vendor's format utility. Most workstation vendors include such a utility. SCSI disks do their own formatting when sent a format command. Just select the format menu option, and the SCSI disk will do the rest. Because the disk does its own 

formatting, there is normally no progress indication. Low-level formatting can take from several minutes to an hour or so.

<BR>

<BR></LI>

<LI>Use a third-party disk management utility. These applications, such as SpeedStor for UNIX, provide a button on their window to directly format the SCSI disk.

<BR>