diff options
Diffstat (limited to 'sag-0.6.1-www/sag-0.6.1.html/x1029.html')
| -rw-r--r-- | sag-0.6.1-www/sag-0.6.1.html/x1029.html | 1720 |
1 files changed, 1720 insertions, 0 deletions
diff --git a/sag-0.6.1-www/sag-0.6.1.html/x1029.html b/sag-0.6.1-www/sag-0.6.1.html/x1029.html new file mode 100644 index 0000000..74c5eb2 --- /dev/null +++ b/sag-0.6.1-www/sag-0.6.1.html/x1029.html @@ -0,0 +1,1720 @@ +<!DOCTYPE HTML PUBLIC "-//Norman Walsh//DTD DocBook HTML 1.0//EN"> +<HTML +><HEAD +><TITLE +>Filesystems</TITLE +><META +NAME="GENERATOR" +CONTENT="Modular DocBook HTML Stylesheet"><LINK +REL="HOME" +TITLE="The Linux System Administrators' Guide" +HREF="book1.html"><LINK +REL="UP" +TITLE="Using Disks and Other Storage Media" +HREF="c701.html"><LINK +REL="PREVIOUS" +TITLE="Partitions" +HREF="x876.html"><LINK +REL="NEXT" +TITLE="Disks without filesystems" +HREF="x1366.html"></HEAD +><BODY +BGCOLOR="#FFFFFF" +TEXT="#000000" +><DIV +CLASS="NAVHEADER" +><TABLE +WIDTH="100%" +BORDER="0" +CELLPADDING="0" +CELLSPACING="0" +><TR +><TH +COLSPAN="3" +ALIGN="center" +>The Linux System Administrators' Guide</TH +></TR +><TR +><TD +WIDTH="10%" +ALIGN="left" +VALIGN="bottom" +><A +HREF="x876.html" +>Prev</A +></TD +><TD +WIDTH="80%" +ALIGN="center" +VALIGN="bottom" +>Chapter 4. Using Disks and Other Storage Media</TD +><TD +WIDTH="10%" +ALIGN="right" +VALIGN="bottom" +><A +HREF="x1366.html" +>Next</A +></TD +></TR +></TABLE +><HR +ALIGN="LEFT" +WIDTH="100%"></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN1029" +>Filesystems</A +></H1 +><DIV +CLASS="SECT2" +><H2 +CLASS="SECT2" +><A +NAME="AEN1031" +>What are filesystems?</A +></H2 +><P +>A <I +CLASS="GLOSSTERM" +>filesystem</I +> is the methods and + data structures that an operating system uses to keep track + of files on a disk or partition; that is, the way the files + are organized on the disk. The word is also used to refer to a + partition or disk that is used to store the files or the type of + the filesystem. Thus, one might say ``I have two filesystems'' + meaning one has two partitions on which one stores files, or + that one is using the ``extended filesystem'', meaning the type + of the filesystem.</P +><P +>The difference between a disk or partition and the filesystem + it contains is important. A few programs (including, + reasonably enough, programs that create filesystems) operate + directly on the raw sectors of a disk or partition; if there + is an existing file system there it will be destroyed or + seriously corrupted. Most programs operate on a filesystem, + and therefore won't work on a partition that doesn't contain + one (or that contains one of the wrong type).</P +><P +>Before a partition or disk can be used as a filesystem, it + needs to be initialized, and the bookkeeping data structures need + to be written to the disk. This process is called + <I +CLASS="GLOSSTERM" +>making a filesystem</I +>.</P +><P +>Most UNIX filesystem types have a similar general + structure, although the exact details vary quite a bit. + The central concepts are <I +CLASS="GLOSSTERM" +>superblock</I +>, + <I +CLASS="GLOSSTERM" +>inode</I +>, <I +CLASS="GLOSSTERM" +>data block</I +>, + <I +CLASS="GLOSSTERM" +>directory block</I +>, and <I +CLASS="GLOSSTERM" +>indirection + block</I +>. The superblock contains information + about the filesystem as a whole, such as its size (the exact + information here depends on the filesystem). An inode contains + all information about a file, except its name. The name is + stored in the directory, together with the number of the inode. + A directory entry consists of a filename and the number of + the inode which represents the file. The inode contains the + numbers of several data blocks, which are used to store the + data in the file. There is space only for a few data block + numbers in the inode, however, and if more are needed, more + space for pointers to the data blocks is allocated dynamically. + These dynamically allocated blocks are indirect blocks; the name + indicates that in order to find the data block, one has to find + its number in the indirect block first.</P +><P +>UNIX filesystems usually allow one to create a + <I +CLASS="GLOSSTERM" +>hole</I +> in a file (this is done with + <TT +CLASS="FUNCTION" +>lseek</TT +>; check the manual page), which means + that the filesystem just pretends that at a particular place in + the file there is just zero bytes, but no actual disk sectors are + reserved for that place in the file (this means that the file + will use a bit less disk space). This happens especially often + for small binaries, Linux shared libraries, some databases, and + a few other special cases. (Holes are implemented by storing a + special value as the address of the data block in the indirect + block or inode. This special address means that no data block + is allocated for that part of the file, ergo, there is a hole + in the file.)</P +><P +>Holes are moderately useful. On the author's system, + a simple measurement showed a potential for about 4 MB of + savings through holes of about 200 MB total used disk space. + That system, however, contains relatively few programs and no + database files.</P +></DIV +><DIV +CLASS="SECT2" +><H2 +CLASS="SECT2" +><A +NAME="AEN1048" +>Filesystems galore</A +></H2 +><P +>Linux supports several types of filesystems. As of this + writing the most important ones are: + + <DIV +CLASS="GLOSSLIST" +><DL +><DT +><B +>minix</B +></DT +><DD +><P +> The oldest, presumed to be the most reliable, but quite + limited in features (some time stamps are missing, at + most 30 character filenames) and restricted in + capabilities (at most 64 MB per filesystem). + </P +></DD +><DT +><B +>xia</B +></DT +><DD +><P +> A modified version of the minix filesystem that lifts + the limits on the filenames and filesystem sizes, + but does not otherwise introduce new features. It is + not very popular, but is reported to work very well. + </P +></DD +><DT +><B +>ext2</B +></DT +><DD +><P +> The most featureful of the native Linux filesystems, + currently also the most popular one. It is designed to + be easily upwards compatible, so that new versions + of the filesystem code do not require re-making the + existing filesystems. + </P +></DD +><DT +><B +>ext</B +></DT +><DD +><P +> An older version of ext2 that wasn't upwards + compatible. It is hardly ever used in new installations + any more, and most people have converted to ext2. + </P +></DD +></DL +></DIV +> + </P +><P +>In addition, support for several foreign filesystem exists, + to make it easier to exchange files with other operating + systems. These foreign filesystems work just like native + ones, except that they may be lacking in some usual UNIX + features, or have curious limitations, or other oddities. + + <DIV +CLASS="GLOSSLIST" +><DL +><DT +><B +>msdos</B +></DT +><DD +><P +> Compatibility with MS-DOS (and OS/2 and Windows NT) + FAT filesystems. + </P +></DD +><DT +><B +>usmdos</B +></DT +><DD +><P +> Extends the msdos filesystem driver under + Linux to get long filenames, owners, + permissions, links, and device files. This allows a normal + msdos filesystem to be used as if it were a + Linux one, thus removing the need for a separate + partition for Linux. + </P +></DD +><DT +><B +>iso9660</B +></DT +><DD +><P +> The standard CD-ROM filesystem; the popular Rock Ridge + extension to the CD-ROM standard that allows longer file + names is supported automatically. + </P +></DD +><DT +><B +>nfs</B +></DT +><DD +><P +> A networked filesystem that allows sharing a filesystem + between many computers to allow easy access to the + files from all of them. + </P +></DD +><DT +><B +>hpfs</B +></DT +><DD +><P +> The OS/2 filesystem. + </P +></DD +><DT +><B +>sysv</B +></DT +><DD +><P +> SystemV/386, Coherent, and Xenix filesystems. + </P +></DD +></DL +></DIV +> + </P +><P +>The choice of filesystem to use depends on the situation. If + compatibility or other reasons make one of the non-native + filesystems necessary, then that one must be used. If one can + choose freely, then it is probably wisest to use ext2, since + it has all the features but does not suffer from lack of + performance.</P +><P +>There is also the proc filesystem, usually accessible as + the <TT +CLASS="FILENAME" +>/proc</TT +> directory, which is not really a + filesystem at all, even though it looks like one. The + proc filesystem makes it easy to access certain kernel + data structures, such as the process list (hence the name). + It makes these + data structures look like a filesystem, and that filesystem + can be manipulated with all the usual file tools. For example, + to get a listing of all processes one might use the + command + +<PRE +CLASS="SCREEN" +><TT +CLASS="PROMPT" +>$</TT +> <TT +CLASS="USERINPUT" +><B +>ls -l /proc</B +></TT +> +<TT +CLASS="COMPUTEROUTPUT" +>total 0 +dr-xr-xr-x 4 root root 0 Jan 31 20:37 1 +dr-xr-xr-x 4 liw users 0 Jan 31 20:37 63 +dr-xr-xr-x 4 liw users 0 Jan 31 20:37 94 +dr-xr-xr-x 4 liw users 0 Jan 31 20:37 95 +dr-xr-xr-x 4 root users 0 Jan 31 20:37 98 +dr-xr-xr-x 4 liw users 0 Jan 31 20:37 99 +-r--r--r-- 1 root root 0 Jan 31 20:37 devices +-r--r--r-- 1 root root 0 Jan 31 20:37 dma +-r--r--r-- 1 root root 0 Jan 31 20:37 filesystems +-r--r--r-- 1 root root 0 Jan 31 20:37 interrupts +-r-------- 1 root root 8654848 Jan 31 20:37 kcore +-r--r--r-- 1 root root 0 Jan 31 11:50 kmsg +-r--r--r-- 1 root root 0 Jan 31 20:37 ksyms +-r--r--r-- 1 root root 0 Jan 31 11:51 loadavg +-r--r--r-- 1 root root 0 Jan 31 20:37 meminfo +-r--r--r-- 1 root root 0 Jan 31 20:37 modules +dr-xr-xr-x 2 root root 0 Jan 31 20:37 net +dr-xr-xr-x 4 root root 0 Jan 31 20:37 self +-r--r--r-- 1 root root 0 Jan 31 20:37 stat +-r--r--r-- 1 root root 0 Jan 31 20:37 uptime +-r--r--r-- 1 root root 0 Jan 31 20:37 version</TT +> +<TT +CLASS="PROMPT" +>$</TT +></PRE +> + + (There will be a few extra files that don't correspond to + processes, though. The above example has been shortened.)</P +><P +>Note that even though it is called a filesystem, no part of + the proc filesystem touches any disk. It exists only in the + kernel's imagination. Whenever anyone tries to look at any + part of the proc filesystem, the kernel makes it look as if + the part existed somewhere, even though it doesn't. So, even + though there is a multi-megabyte <TT +CLASS="FILENAME" +>/proc/kcore</TT +> file, + it doesn't take any disk space.</P +></DIV +><DIV +CLASS="SECT2" +><H2 +CLASS="SECT2" +><A +NAME="AEN1104" +>Which filesystem should be used?</A +></H2 +><P +>There is usually little point in using many different + filesystems. Currently, ext2fs is the most popular one, and + it is probably the wisest choice. Depending on the overhead + for bookkeeping structures, speed, (perceived) reliability, + compatibility, and various other reasons, it may be advisable + to use another file system. This needs to be decided on a + case-by-case basis.</P +></DIV +><DIV +CLASS="SECT2" +><H2 +CLASS="SECT2" +><A +NAME="AEN1107" +>Creating a filesystem</A +></H2 +><P +>Filesystems are created, i.e., initialized, with the <B +CLASS="COMMAND" +>mkfs</B +> + command. There is actually a separate program for each filesystem + type. <B +CLASS="COMMAND" +>mkfs</B +> is just a front end that runs the appropriate + program depending on the desired filesystem type. The type is + selected with the <SPAN +CLASS="OPTION" +>-t fstype</SPAN +> option.</P +><P +>The programs called by <B +CLASS="COMMAND" +>mkfs</B +> have slightly + different command line interfaces. The common and most important + options are summarized below; see the manual pages for more. + + <DIV +CLASS="GLOSSLIST" +><DL +><DT +><B +><SPAN +CLASS="OPTION" +>-t fstype</SPAN +></B +></DT +><DD +><P +> Select the type of the filesystem. + </P +></DD +><DT +><B +><SPAN +CLASS="OPTION" +>-c</SPAN +></B +></DT +><DD +><P +> Search for bad blocks and initialize the bad + block list accordingly. + </P +></DD +><DT +><B +>-l filename</B +></DT +><DD +><P +> Read the initial bad block list from the name file. + </P +></DD +></DL +></DIV +> + </P +><P +>To create an ext2 filesystem on a floppy, one would give the + following commands: + +<PRE +CLASS="SCREEN" +><TT +CLASS="PROMPT" +>$</TT +> <TT +CLASS="USERINPUT" +><B +>fdformat -n /dev/fd0H1440</B +></TT +> +<TT +CLASS="COMPUTEROUTPUT" +>Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. +Formatting ... done</TT +> +<TT +CLASS="PROMPT" +>$</TT +> <TT +CLASS="USERINPUT" +><B +>badblocks /dev/fd0H1440 1440 $>$ bad-blocks</B +></TT +> +<TT +CLASS="PROMPT" +>$</TT +> <TT +CLASS="USERINPUT" +><B +>mkfs -t ext2 -l bad-blocks /dev/fd0H1440</B +></TT +> +<TT +CLASS="COMPUTEROUTPUT" +>mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10 +360 inodes, 1440 blocks +72 blocks (5.00%) reserved for the super user +First data block=1 +Block size=1024 (log=0) +Fragment size=1024 (log=0) +1 block group +8192 blocks per group, 8192 fragments per group +360 inodes per group + +Writing inode tables: done +Writing superblocks and filesystem accounting information: done</TT +> +<TT +CLASS="PROMPT" +>$</TT +></PRE +> + + First, the floppy was formatted (the <SPAN +CLASS="OPTION" +>-n</SPAN +> option + prevents validation, i.e., bad block checking). Then bad blocks + were searched with <B +CLASS="COMMAND" +>badblocks</B +>, with the output + redirected to a file, <TT +CLASS="FILENAME" +>bad-blocks</TT +>. Finally, + the filesystem was created, with the bad block list initialized + by whatever <B +CLASS="COMMAND" +>badblocks</B +> found.</P +><P +>The <SPAN +CLASS="OPTION" +>-c</SPAN +> option could have been used with + <B +CLASS="COMMAND" +>mkfs</B +> instead of <B +CLASS="COMMAND" +>badblocks</B +> + and a separate file. The example below does that. + +<PRE +CLASS="SCREEN" +><TT +CLASS="PROMPT" +>$</TT +> <TT +CLASS="USERINPUT" +><B +>mkfs -t ext2 -c /dev/fd0H1440</B +></TT +> +<TT +CLASS="COMPUTEROUTPUT" +>mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10 +360 inodes, 1440 blocks +72 blocks (5.00%) reserved for the super user +First data block=1 +Block size=1024 (log=0) +Fragment size=1024 (log=0) +1 block group +8192 blocks per group, 8192 fragments per group +360 inodes per group + +Checking for bad blocks (read-only test): done +Writing inode tables: done +Writing superblocks and filesystem accounting information: done</TT +> +<TT +CLASS="PROMPT" +>$</TT +></PRE +> + + The <SPAN +CLASS="OPTION" +>-c</SPAN +> option is more convenient than a separate use of + <B +CLASS="COMMAND" +>badblocks</B +>, but <B +CLASS="COMMAND" +>badblocks</B +> is necessary for checking + after the filesystem has been created.</P +><P +>The process to prepare filesystems on hard disks or + partitions is the same as for floppies, except that the formatting + isn't needed.</P +></DIV +><DIV +CLASS="SECT2" +><H2 +CLASS="SECT2" +><A +NAME="MOUNT-AND-UMOUNT" +>Mounting and unmounting</A +></H2 +><P +>Before one can use a filesystem, it has to be <I +CLASS="GLOSSTERM" +>mounted</I +>. + The operating system then does various bookkeeping things to + make sure that everything works. Since all files in UNIX are + in a single directory tree, the mount operation will make it + look like the contents of the new filesystem are the contents of + an existing subdirectory in some already mounted filesystem.</P +><P +>For example, <A +HREF="x1029.html#HD-MOUNT-ROOT" +>Figure 4-3</A +> shows three + separate filesystems, each with their own root directory. + When the last two filesystems are mounted below <TT +CLASS="FILENAME" +>/home</TT +> + and <TT +CLASS="FILENAME" +>/usr</TT +>, respectively, on the first filesystem, we + can get a single directory tree, as in + <A +HREF="x1029.html#HD-MOUNT-ALL" +>Figure 4-4</A +>.</P +><DIV +CLASS="FIGURE" +><P +><B +><A +NAME="HD-MOUNT-ROOT" +>Figure 4-3. Three separate filesystems.</A +></B +></P +><P +><IMG +SRC="hd-mount-separate.gif"></P +></DIV +><DIV +CLASS="FIGURE" +><P +><B +><A +NAME="HD-MOUNT-ALL" +>Figure 4-4. <TT +CLASS="FILENAME" +>/home</TT +> and <TT +CLASS="FILENAME" +>/usr</TT +> have been mounted.</A +></B +></P +><P +><IMG +SRC="hd-mount-mounted.gif"></P +></DIV +><P +>The mounts could be done as in the following example: + +<PRE +CLASS="SCREEN" +><TT +CLASS="PROMPT" +>$</TT +> <TT +CLASS="USERINPUT" +><B +>mount /dev/hda2 /home</B +></TT +> +<TT +CLASS="PROMPT" +>$</TT +> <TT +CLASS="USERINPUT" +><B +>mount /dev/hda3 /usr</B +></TT +> +<TT +CLASS="PROMPT" +>$</TT +></PRE +> + + The <B +CLASS="COMMAND" +>mount</B +> command takes two arguments. + The first one is the device file corresponding to the disk + or partition containing the filesystem. The second one is + the directory below which it will be mounted. After these + commands the contents of the two filesystems look just + like the contents of the <TT +CLASS="FILENAME" +>/home</TT +> and + <TT +CLASS="FILENAME" +>/usr</TT +> directories, respectively. One would + then say that ``<TT +CLASS="FILENAME" +>/dev/hda2</TT +> <I +CLASS="GLOSSTERM" +>is + mounted on</I +> <TT +CLASS="FILENAME" +>/home</TT +>'', and + similarly for <TT +CLASS="FILENAME" +>/usr</TT +>. To look at either + filesystem, one would look at the contents of the directory + on which it has been mounted, just as if it were any other + directory. Note the difference between the device file, + <TT +CLASS="FILENAME" +>/dev/hda2</TT +>, and the mounted-on directory, + <TT +CLASS="FILENAME" +>/home</TT +>. The device file gives access to the + raw contents of the disk, the mounted-on directory gives access + to the files on the disk. The mounted-on directory is called + the <I +CLASS="GLOSSTERM" +>mount point</I +>.</P +><P +>Linux supports many filesystem types. <B +CLASS="COMMAND" +>mount</B +> tries to + guess the type of the filesystem. You can also use the + <SPAN +CLASS="OPTION" +>-t fstype</SPAN +> option to specify the type directly; + this is sometimes necessary, since the heuristics <B +CLASS="COMMAND" +>mount</B +> + uses do not always work. For example, to mount an MS-DOS + floppy, you could use the following command: + +<PRE +CLASS="SCREEN" +><TT +CLASS="PROMPT" +>$</TT +> <TT +CLASS="USERINPUT" +><B +>mount -t msdos /dev/fd0 /floppy</B +></TT +> +<TT +CLASS="PROMPT" +>$</TT +></PRE +> + </P +><P +>The mounted-on directory need not be empty, although it + must exist. Any files in it, however, will be inaccessible by + name while the filesystem is mounted. (Any files that have + already been opened will still be accessible. Files that + have hard links from other directories can be accessed using + those names.) There is no harm done with this, and it can even + be useful. For instance, some people like to have <TT +CLASS="FILENAME" +>/tmp</TT +> + and <TT +CLASS="FILENAME" +>/var/tmp</TT +> synonymous, and make <TT +CLASS="FILENAME" +>/tmp</TT +> be a symbolic + link to <TT +CLASS="FILENAME" +>/var/tmp</TT +>. When the system is booted, before + the <TT +CLASS="FILENAME" +>/var</TT +> filesystem is mounted, a <TT +CLASS="FILENAME" +>/var/tmp</TT +> directory + residing on the root filesystem is used instead. When <TT +CLASS="FILENAME" +>/var</TT +> + is mounted, it will make the <TT +CLASS="FILENAME" +>/var/tmp</TT +> directory on the root + filesystem inaccessible. If <TT +CLASS="FILENAME" +>/var/tmp</TT +> didn't exist on the + root filesystem, it would be impossible to use temporary files + before mounting <TT +CLASS="FILENAME" +>/var</TT +>.</P +><P +>If you don't intend to write anything to the filesystem, use + the <SPAN +CLASS="OPTION" +>-r</SPAN +> switch for <B +CLASS="COMMAND" +>mount</B +> to do a <I +CLASS="GLOSSTERM" +>readonly + mount</I +>. This will make the kernel stop any attempts at + writing to the filesystem, and will also stop the kernel from + updating file access times in the inodes. Read-only mounts + are necessary for unwritable media, e.g., CD-ROM's.</P +><P +>The alert reader has already noticed a slight + logistical problem. How is the first filesystem (called the <I +CLASS="GLOSSTERM" +>root + filesystem</I +>, because it contains the root directory) mounted, + since it obviously can't be mounted on another filesystem? + Well, the answer is that it is done by magic. + + <A +NAME="AEN1217" +HREF="#FTN.AEN1217" +>[1]</A +> + + The root filesystem is magically mounted at boot time, + and one can rely on it to always be mounted. If the + root filesystem can't be mounted, the system does not boot. + The name of the filesystem that is magically mounted as root + is either compiled into the kernel, or set using LILO or + <B +CLASS="COMMAND" +>rdev</B +>.</P +><P +>The root filesystem is usually first mounted readonly. + The startup scripts will then run <B +CLASS="COMMAND" +>fsck</B +> + to verify its validity, and if there are no problems, they + will <I +CLASS="GLOSSTERM" +>re-mount</I +> it so that writes will + also be allowed. <B +CLASS="COMMAND" +>fsck</B +> must not be run on a + mounted filesystem, since any changes to the filesystem while + <B +CLASS="COMMAND" +>fsck</B +> is running <I +CLASS="EMPHASIS" +>will</I +> + cause trouble. Since the root filesystem is mounted readonly + while it is being checked, <B +CLASS="COMMAND" +>fsck</B +> can fix any + problems without worry, since the remount operation will flush + any metadata that the filesystem keeps in memory.</P +><P +>On many systems there are other filesystems that should + also be mounted automatically at boot time. These are specified + in the <TT +CLASS="FILENAME" +>/etc/fstab</TT +> file; see the fstab man + page for details on the format. The details of exactly when the + extra filesystems are mounted depend on many factors, and can be + configured by each administrator if need be; see + <A +HREF="c1582.html" +>Chapter 6</A +>.</P +><P +>When a filesystem no longer needs to be mounted, it can be + unmounted with <B +CLASS="COMMAND" +>umount</B +>. + + <A +NAME="AEN1232" +HREF="#FTN.AEN1232" +>[2]</A +> + + <B +CLASS="COMMAND" +>umount</B +> takes one argument: + either the device file or the mount point. + For example, to unmount the directories of + the previous example, one could use the commands + +<PRE +CLASS="SCREEN" +><TT +CLASS="PROMPT" +>$</TT +> <TT +CLASS="USERINPUT" +><B +>umount /dev/hda2</B +></TT +> +<TT +CLASS="PROMPT" +>$</TT +> <TT +CLASS="USERINPUT" +><B +>umount /usr</B +></TT +> +<TT +CLASS="PROMPT" +>$</TT +></PRE +> + </P +><P +>See the man page for further instructions on how to + use the command. It is imperative that you always unmount a + mounted floppy. <I +CLASS="EMPHASIS" +>Don't just pop the floppy out of + the drive!</I +> Because of disk caching, the data is + not necessarily written to the floppy until you unmount it, + so removing the floppy from the drive too early might cause the + contents to become garbled. If you only read from the floppy, + this is not very likely, but if you write, even accidentally, + the result may be catastrophic.</P +><P +>Mounting and unmounting requires super user privileges, i.e., + only root can do it. The reason for this is that if any + user can mount a floppy on any directory, then it is rather easy + to create a floppy with, say, a Trojan horse disguised as + <TT +CLASS="FILENAME" +>/bin/sh</TT +>, or any other often used program. However, it is + often necessary to allow users to use floppies, and there are + several ways to do this: + + <P +></P +><UL +><LI +><P +>Give the users the root password. This is + obviously bad security, but is the easiest solution. It works + well if there is no need for security anyway, which is the case + on many non-networked, personal systems.</P +></LI +><LI +><P +>Use a program such as <B +CLASS="COMMAND" +>sudo</B +> to allow users to + use mount. This is still bad security, but doesn't + directly give super user privileges to + everyone. + <A +NAME="AEN1252" +HREF="#FTN.AEN1252" +>[3]</A +> + </P +></LI +><LI +><P +>Make the users use <B +CLASS="COMMAND" +>mtools</B +>, a package for manipulating + MS-DOS filesystems, without mounting them. This works + well if MS-DOS floppies are all that is needed, + but is rather awkward otherwise. + </P +></LI +><LI +><P +>List the floppy devices and their allowable mount points + together with the suitable options in <TT +CLASS="FILENAME" +>/etc/fstab</TT +>. + + </P +></LI +></UL +> + + The last alternative can be implemented by adding a line like + the following to the \fn{/etc/fstab} file: + +<PRE +CLASS="SCREEN" +>/dev/fd0 /floppy msdos user,noauto 0 0</PRE +> + + The columns are: device file to mount, directory to mount + on, filesystem type, options, backup frequency (used by + <B +CLASS="COMMAND" +>dump</B +>), and <B +CLASS="COMMAND" +>fsck</B +> pass number + (to specify the order in which filesystems should be checked + upon boot; 0 means no check).</P +><P +>The <SPAN +CLASS="OPTION" +>noauto</SPAN +> option stops this mount to be done + automatically when the system is started (i.e., it stops + <B +CLASS="COMMAND" +>mount -a</B +> from mounting it). The <SPAN +CLASS="OPTION" +>user</SPAN +> option + allows any user to mount the filesystem, and, because of security + reasons, disallows execution of programs (normal or setuid) + and interpretation of device files from the mounted filesystem. + After this, any user can mount a floppy with an msdos + filesystem with the following command: + +<PRE +CLASS="SCREEN" +><TT +CLASS="PROMPT" +>$</TT +> <TT +CLASS="USERINPUT" +><B +>mount /floppy</B +></TT +> +<TT +CLASS="PROMPT" +>$</TT +></PRE +> + + The floppy can (and needs to, of course) be unmounted with + the corresponding \cmd{umount} command.</P +><P +>If you want to provide access to several types of floppies, + you need to give several mount points. The settings can be + different for each mount point. For example, to give access + to both MS-DOS and ext2 floppies, you could have the following + to lines in <TT +CLASS="FILENAME" +>/etc/fstab</TT +>: + +<PRE +CLASS="SCREEN" +>/dev/fd0 /dosfloppy msdos user,noauto 0 0 +/dev/fd0 /ext2floppy ext2 user,noauto 0 0</PRE +> + + For MS-DOS filesystems (not just floppies), you probably want + to restrict access to it by using the <SPAN +CLASS="OPTION" +>uid</SPAN +>, + <SPAN +CLASS="OPTION" +>gid</SPAN +>, and <SPAN +CLASS="OPTION" +>umask</SPAN +> filesystem + options, described in detail on the <B +CLASS="COMMAND" +>mount</B +> + manual page. If you aren't careful, mounting an MS-DOS filesystem + gives everyone at least read access to the files in it, which + is not a good idea.</P +></DIV +><DIV +CLASS="SECT2" +><H2 +CLASS="SECT2" +><A +NAME="AEN1278" +>Checking filesystem integrity with <B +CLASS="COMMAND" +>fsck</B +></A +></H2 +><P +>Filesystems are complex creatures, and as such, they + tend to be somewhat error-prone. A filesystem's correctness and + validity can be checked using the <B +CLASS="COMMAND" +>fsck</B +> command. + It can be instructed to repair any minor problems it finds, and to + alert the user if there any unrepairable problems. Fortunately, + the code to implement filesystems is debugged quite effectively, + so there are seldom any problems at all, and they are usually + caused by power failures, failing hardware, or operator errors; + for example, by not shutting down the system properly.</P +><P +>Most systems are setup to run <B +CLASS="COMMAND" +>fsck</B +> + automatically at boot time, so that any errors are detected + (and hopefully corrected) before the system is used. Use of + a corrupted filesystem tends to make things worse: if the + data structures are messed up, using the filesystem will + probably mess them up even more, resulting in more data loss. + However, <B +CLASS="COMMAND" +>fsck</B +> can take a while to run on big + filesystems, and since errors almost never occur if the system + has been shut down properly, a couple of tricks are used to + avoid doing the checks in such cases. The first is that if + the file <TT +CLASS="FILENAME" +>/etc/fastboot</TT +> exists, no checks + are made. The second is that the ext2 filesystem has a special + marker in its superblock that tells whether the filesystem + was unmounted properly after the previous mount. This allows + <B +CLASS="COMMAND" +>e2fsck</B +> (the version of <B +CLASS="COMMAND" +>fsck</B +> + for the ext2 filesystem) to avoid checking the filesystem if + the flag indicates that the unmount was done (the assumption + being that a proper unmount indicates no problems). Whether the + <TT +CLASS="FILENAME" +>/etc/fastboot</TT +> trick works on your system + depends on your startup scripts, but the ext2 trick works + every time you use <B +CLASS="COMMAND" +>e2fsck</B +>. It has to be + explicitly bypassed with an option to <B +CLASS="COMMAND" +>e2fsck</B +> + to be avoided. (See the <B +CLASS="COMMAND" +>e2fsck</B +> man page for + details on how.)</P +><P +>The automatic checking only works for the + filesystems that are mounted automatically at boot time. + Use <B +CLASS="COMMAND" +>fsck</B +> manually to check other filesystems, + e.g., floppies.</P +><P +>If <B +CLASS="COMMAND" +>fsck</B +> finds unrepairable problems, + you need either in-depth knowlege of how filesystems work in + general, and the type of the corrupt filesystem in particular, + or good backups. The latter is easy (although sometimes tedious) + to arrange, the former can sometimes be arranged via a friend, + the Linux newsgroups and mailing lists, or some other source of + support, if you don't have the know-how yourself. I'd like to + tell you more about it, but my lack of education and experience + in this regard hinders me. The <B +CLASS="COMMAND" +>debugfs</B +> + program by Theodore T'so should be useful.</P +><P +><B +CLASS="COMMAND" +>fsck</B +> must only be run on unmounted + filesystems, never on mounted filesystems (with the exception of + the read-only root during startup). This is because it accesses + the raw disk, and can therefore modify the filesystem without the + operating system realizing it. There <I +CLASS="EMPHASIS" +>will</I +> + be trouble, if the operating system is confused.</P +></DIV +><DIV +CLASS="SECT2" +><H2 +CLASS="SECT2" +><A +NAME="AEN1301" +>Checking for disk errors with <B +CLASS="COMMAND" +>badblocks</B +></A +></H2 +><P +>It can be a good idea to periodically check for bad blocks. + This is done with the <B +CLASS="COMMAND" +>badblocks</B +> command. It outputs + a list of the numbers of all bad blocks it can find. This list + can be fed to <B +CLASS="COMMAND" +>fsck</B +> to be recorded + in the filesystem data structures so that the operating system + won't try to use the bad blocks for storing data. + The following example will show how this could be done. + +<PRE +CLASS="SCREEN" +><TT +CLASS="PROMPT" +>$</TT +> <TT +CLASS="USERINPUT" +><B +>badblocks /dev/fd0H1440 1440 > bad-blocks</B +></TT +> +<TT +CLASS="PROMPT" +>$</TT +> <TT +CLASS="USERINPUT" +><B +>fsck -t ext2 -l bad-blocks /dev/fd0H1440</B +></TT +> +<TT +CLASS="COMPUTEROUTPUT" +>Parallelizing fsck version 0.5a (5-Apr-94) +e2fsck 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10 +Pass 1: Checking inodes, blocks, and sizes +Pass 2: Checking directory structure +Pass 3: Checking directory connectivity +Pass 4: Check reference counts. +Pass 5: Checking group summary information. + +/dev/fd0H1440: ***** FILE SYSTEM WAS MODIFIED ***** +/dev/fd0H1440: 11/360 files, 63/1440 blocks</TT +> +<TT +CLASS="PROMPT" +>$</TT +></PRE +> + + If badblocks reports a block that was already used, + <B +CLASS="COMMAND" +>e2fsck</B +> will try to move the block to another + place. If the block was really bad, not just marginal, the + contents of the file may be corrupted.</P +></DIV +><DIV +CLASS="SECT2" +><H2 +CLASS="SECT2" +><A +NAME="AEN1315" +>Fighting fragmentation</A +></H2 +><P +>When a file is written to disk, it can't always be written + in consecutive blocks. A file that is not stored in + consecutive blocks is <I +CLASS="GLOSSTERM" +>fragmented</I +>. It takes longer + to read a fragmented file, since the disk's read-write head + will have to move more. It is desireable to avoid fragmentation, + although it is less of a problem in a system with a good buffer + cache with read-ahead.</P +><P +>The ext2 filesystem attempts to keep fragmentation at a + minimum, by keeping all blocks in a file close together, even if + they can't be stored in consecutive sectors. Ext2 effectively + always allocates the free block that is nearest to other blocks + in a file. For ext2, it is therefore seldom necessary to worry + about fragmentation. There is a program for defragmenting an + ext2 filesystem, see XXX (ext2-defrag) in the bibliography.</P +><P +>There are many MS-DOS defragmentation programs that + move blocks around in the filesystem to remove fragmentation. + For other filesystems, defragmentation must be done by backing + up the filesystem, re-creating it, and restoring the files + from backups. Backing up a filesystem before defragmening is + a good idea for all filesystems, since many things can go wrong + during the defragmentation.</P +></DIV +><DIV +CLASS="SECT2" +><H2 +CLASS="SECT2" +><A +NAME="AEN1321" +>Other tools for all filesystems</A +></H2 +><P +>Some other tools are also useful for managing filesystems. + <B +CLASS="COMMAND" +>df</B +> shows the free disk space on one or more + filesystems; <B +CLASS="COMMAND" +>du</B +> shows how much disk space a + directory and all its files contain. These can be used to hunt + down disk space wasters.</P +><P +><B +CLASS="COMMAND" +>sync</B +> forces all unwritten blocks + in the buffer cache (see <A +HREF="x1551.html" +>the section called <I +>The buffer cache</I +> in Chapter 5</A +>) to + be written to disk. It is seldom necessary to do this by + hand; the daemon process <B +CLASS="COMMAND" +>update</B +> does + this automatically. It can be useful in catastrophies, + for example if <B +CLASS="COMMAND" +>update</B +> or its helper + process <B +CLASS="COMMAND" +>bdflush</B +> dies, or if you must + turn off power <I +CLASS="EMPHASIS" +>now</I +> and can't wait for + <B +CLASS="COMMAND" +>update</B +> to run.</P +></DIV +><DIV +CLASS="SECT2" +><H2 +CLASS="SECT2" +><A +NAME="AEN1334" +>Other tools for the ext2 filesystem</A +></H2 +><P +>In addition to the filesystem creator (<B +CLASS="COMMAND" +>mke2fs</B +>) and + checker (<B +CLASS="COMMAND" +>e2fsck</B +>) accessible directly or via the + filesystem type independent front ends, the ext2 + filesystem has some additional tools that can be useful.</P +><P +><B +CLASS="COMMAND" +>tune2fs</B +> adjusts filesystem parameters. Some of the + more interesting parameters are: + + <P +></P +><UL +><LI +><P +> A maximal mount count. <B +CLASS="COMMAND" +>e2fsck</B +> enforces a check when + filesystem has been mounted too many times, even if + the clean flag is set. For a system that is used for + developing or testing the system, it might be a good + idea to reduce this limit. + </P +></LI +><LI +><P +> A maximal time between checks. <B +CLASS="COMMAND" +>e2fsck</B +> can also enforce + a maximal time between two checks, even if the clean + flag is set, and the filesystem hasn't been mounted very + often. This can be disabled, however. + </P +></LI +><LI +><P +> Number of blocks reserved for root. Ext2 + reserves some blocks for root so that if the + filesystem fills up, it is still possible to do system + administration without having to delete anything. The + reserved amount is by default 5 percent, which on most disks + isn't enough to be wasteful. However, for floppies there + is no point in reserving any blocks. + </P +></LI +></UL +> + + See the <B +CLASS="COMMAND" +>tune2fs</B +> manual page for more + information.</P +><P +><B +CLASS="COMMAND" +>dumpe2fs</B +> shows information about an ext2 filesystem, mostly + from the superblock. <A +HREF="x1029.html#DUMPE2FS-OUTPUT" +>Figure 4-5</A +> shows + a sample output. Some of the information in the output is + technical and requires understanding of how the filesystem + works (see appendix XXX ext2fspaper), but much of + it is readily understandable even for layadmins.</P +><DIV +CLASS="FIGURE" +><P +><B +><A +NAME="DUMPE2FS-OUTPUT" +>Figure 4-5. Sample output from <B +CLASS="COMMAND" +>dumpe2fs</B +></A +></B +></P +><P +CLASS="LITERALLAYOUT" +>dumpe2fs 0.5b, 11-Mar-95 for EXT2 FS 0.5a, 94/10/23<br> +Filesystem magic number: 0xEF53<br> +Filesystem state: clean<br> +Errors behavior: Continue<br> +Inode count: 360<br> +Block count: 1440<br> +Reserved block count: 72<br> +Free blocks: 1133<br> +Free inodes: 326<br> +First block: 1<br> +Block size: 1024<br> +Fragment size: 1024<br> +Blocks per group: 8192<br> +Fragments per group: 8192<br> +Inodes per group: 360<br> +Last mount time: Tue Aug 8 01:52:52 1995<br> +Last write time: Tue Aug 8 01:53:28 1995<br> +Mount count: 3<br> +Maximum mount count: 20<br> +Last checked: Tue Aug 8 01:06:31 1995<br> +Check interval: 0<br> +Reserved blocks uid: 0 (user root)<br> +Reserved blocks gid: 0 (group root)<br> +<br> +Group 0:<br> + Block bitmap at 3, Inode bitmap at 4, Inode table at 5<br> + 1133 free blocks, 326 free inodes, 2 directories<br> + Free blocks: 307-1439<br> + Free inodes: 35-360</P +></DIV +><P +><B +CLASS="COMMAND" +>debugfs</B +> is a filesystem debugger. + It allows direct access to the filesystem data structures + stored on disk and can thus be used to repair a disk that is so + broken that <B +CLASS="COMMAND" +>fsck</B +> can't fix it automatically. + It has also been known to be used to recover deleted files. + However, <B +CLASS="COMMAND" +>debugfs</B +> very much requires that + you understand what you're doing; a failure to understand can + destroy all your data.</P +><P +><B +CLASS="COMMAND" +>dump</B +> and <B +CLASS="COMMAND" +>restore</B +> can be used to back up an + ext2 filesystem. They are ext2 specific versions of the + traditional UNIX backup tools. See <A +HREF="c2187.html" +>Chapter 10</A +> + for more information on backups.</P +></DIV +></DIV +><H3 +>Notes</H3 +><TABLE +BORDER="0" +CLASS="FOOTNOTES" +WIDTH="100%" +><TR +><TD +ALIGN="LEFT" +VALIGN="TOP" +WIDTH="5%" +><A +NAME="FTN.AEN1217" +HREF="x1029.html#AEN1217" +>[1]</A +></TD +><TD +ALIGN="LEFT" +VALIGN="TOP" +WIDTH="95%" +><P +>For more + information, see the kernel source or the Kernel Hackers' + Guide.</P +></TD +></TR +><TR +><TD +ALIGN="LEFT" +VALIGN="TOP" +WIDTH="5%" +><A +NAME="FTN.AEN1232" +HREF="x1029.html#AEN1232" +>[2]</A +></TD +><TD +ALIGN="LEFT" +VALIGN="TOP" +WIDTH="95%" +><P +>It should of course be + <B +CLASS="COMMAND" +>unmount</B +>, but the n mysteriously disappeared in + the 70's, and hasn't been seen since. Please return it to Bell + Labs, NJ, if you find it.</P +></TD +></TR +><TR +><TD +ALIGN="LEFT" +VALIGN="TOP" +WIDTH="5%" +><A +NAME="FTN.AEN1252" +HREF="x1029.html#AEN1252" +>[3]</A +></TD +><TD +ALIGN="LEFT" +VALIGN="TOP" +WIDTH="95%" +><P +>It requires several seconds of hard + thinking on the users' behalf.</P +></TD +></TR +></TABLE +><DIV +CLASS="NAVFOOTER" +><HR +ALIGN="LEFT" +WIDTH="100%"><TABLE +WIDTH="100%" +BORDER="0" +CELLPADDING="0" +CELLSPACING="0" +><TR +><TD +WIDTH="33%" +ALIGN="left" +VALIGN="top" +><A +HREF="x876.html" +>Prev</A +></TD +><TD +WIDTH="34%" +ALIGN="center" +VALIGN="top" +><A +HREF="book1.html" +>Home</A +></TD +><TD +WIDTH="33%" +ALIGN="right" +VALIGN="top" +><A +HREF="x1366.html" +>Next</A +></TD +></TR +><TR +><TD +WIDTH="33%" +ALIGN="left" +VALIGN="top" +>Partitions</TD +><TD +WIDTH="34%" +ALIGN="center" +VALIGN="top" +><A +HREF="c701.html" +>Up</A +></TD +><TD +WIDTH="33%" +ALIGN="right" +VALIGN="top" +>Disks without filesystems</TD +></TR +></TABLE +></DIV +></BODY +></HTML +>
\ No newline at end of file |