diff options
Diffstat (limited to 'sag-0.6.1-www/sag-0.6.1.html/x1551.html')
| -rw-r--r-- | sag-0.6.1-www/sag-0.6.1.html/x1551.html | 308 |
1 files changed, 308 insertions, 0 deletions
diff --git a/sag-0.6.1-www/sag-0.6.1.html/x1551.html b/sag-0.6.1-www/sag-0.6.1.html/x1551.html new file mode 100644 index 0000000..4bd5990 --- /dev/null +++ b/sag-0.6.1-www/sag-0.6.1.html/x1551.html @@ -0,0 +1,308 @@ +<!DOCTYPE HTML PUBLIC "-//Norman Walsh//DTD DocBook HTML 1.0//EN"> +<HTML +><HEAD +><TITLE +>The buffer cache</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="Memory Management" +HREF="c1450.html"><LINK +REL="PREVIOUS" +TITLE="Allocating swap space" +HREF="x1532.html"><LINK +REL="NEXT" +TITLE="Boots And Shutdowns" +HREF="c1582.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="x1532.html" +>Prev</A +></TD +><TD +WIDTH="80%" +ALIGN="center" +VALIGN="bottom" +>Chapter 5. Memory Management</TD +><TD +WIDTH="10%" +ALIGN="right" +VALIGN="bottom" +><A +HREF="c1582.html" +>Next</A +></TD +></TR +></TABLE +><HR +ALIGN="LEFT" +WIDTH="100%"></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="BUFFER-CACHE" +>The buffer cache</A +></H1 +><P +>Reading from a disk + + <A +NAME="AEN1554" +HREF="#FTN.AEN1554" +>[1]</A +> + + is very slow compared to accessing (real) memory. In addition, + it is common to read the same part of a disk several times + during relatively short periods of time. For example, one + might first read an e-mail message, then read the letter into + an editor when replying to it, then make the mail program read + it again when copying it to a folder. Or, consider how often + the command <B +CLASS="COMMAND" +>ls</B +> might be run on a system with + many users. By reading the information from disk only once + and then keeping it in memory until no longer needed, one can + speed up all but the first read. This is called <I +CLASS="GLOSSTERM" +>disk + buffering</I +>, and the memory used for the purpose is + called the <I +CLASS="GLOSSTERM" +>buffer cache</I +>.</P +><P +>Since memory is, unfortunately, a finite, nay, scarce + resource, the buffer cache usually cannot be big enough (it + can't hold all the data one ever wants to use). When the cache + fills up, the data that has been unused for the longest time + is discarded and the memory thus freed is used for the new + data.</P +><P +>Disk buffering works for writes as well. On the one hand, + data that is written is often soon read again (e.g., a source + code file is saved to a file, then read by the compiler), + so putting data that is written in the cache is a good idea. + On the other hand, by only putting the data into the cache, not + writing it to disk at once, the program that writes runs quicker. + The writes can then be done in the background, without slowing + down the other programs.</P +><P +>Most operating systems have buffer caches (although + they might be called something else), but not all of + them work according to the above principles. Some are + <I +CLASS="GLOSSTERM" +>write-through</I +>: the data is written to disk + at once (it is kept in the cache as well, of course). The cache + is called <I +CLASS="GLOSSTERM" +>write-back</I +> if the writes are done + at a later time. Write-back is more efficient than write-through, + but also a bit more prone to errors: if the machine crashes, + or the power is cut at a bad moment, or the floppy is removed + from the disk drive before the data in the cache waiting to be + written gets written, the changes in the cache are usually lost. + This might even mean that the filesystem (if there is one) is + not in full working order, perhaps because the unwritten data + held important changes to the bookkeeping information.</P +><P +>Because of this, you should never turn off the + power without using a proper shutdown procedure (see <A +HREF="c1582.html" +>Chapter 6</A +>), or remove a floppy from the + disk drive until it has been unmounted (if it was mounted) + or after whatever program is using it has signaled that it + is finished and the floppy drive light doesn't shine anymore. + The <B +CLASS="COMMAND" +>sync</B +> command <I +CLASS="GLOSSTERM" +>flushes</I +> + the buffer, i.e., forces all unwritten data to be written to disk, + and can be used when one wants to be sure that everything is + safely written. In traditional UNIX systems, there is a program + called <B +CLASS="COMMAND" +>update</B +> running in the background + which does a <B +CLASS="COMMAND" +>sync</B +> every 30 seconds, so + it is usually not necessary to use <B +CLASS="COMMAND" +>sync</B +>. + Linux has an additional daemon, <B +CLASS="COMMAND" +>bdflush</B +>, + which does a more imperfect sync more frequently to avoid the + sudden freeze due to heavy disk I/O that <B +CLASS="COMMAND" +>sync</B +> + sometimes causes.</P +><P +>Under Linux, <B +CLASS="COMMAND" +>bdflush</B +> is started by + <B +CLASS="COMMAND" +>update</B +>. There is usually no reason to worry + about it, but if <B +CLASS="COMMAND" +>bdflush</B +> happens to die for + some reason, the kernel will warn about this, and you should + start it by hand (<B +CLASS="COMMAND" +>/sbin/update</B +>).</P +><P +>The cache does not actually buffer files, but blocks, which + are the smallest units of disk I/O (under Linux, they are usually + 1 kB). This way, also directories, super blocks, other filesystem + bookkeeping data, and non-filesystem disks are cached.</P +><P +>The effectiveness of a cache is primarily decided by its + size. A small cache is next to useless: it will hold so little + data that all cached data is flushed from the cache before it + is reused. The critical size depends on how much data is read + and written, and how often the same data is accessed. The only + way to know is to experiment.</P +><P +>If the cache is of a fixed size, it is not very good to have + it too big, either, because that might make the free memory too + small and cause swapping (which is also slow). To make the most + efficient use of real memory, Linux automatically uses all free + RAM for buffer cache, but also automatically makes the cache + smaller when programs need more memory.</P +><P +>Under Linux, you do not need to do anything to make use + of the cache, it happens completely automatically. Except for + following the proper procedures for shutdown and removing + floppies, you do not need to worry about it. </P +></DIV +><H3 +>Notes</H3 +><TABLE +BORDER="0" +CLASS="FOOTNOTES" +WIDTH="100%" +><TR +><TD +ALIGN="LEFT" +VALIGN="TOP" +WIDTH="5%" +><A +NAME="FTN.AEN1554" +HREF="x1551.html#AEN1554" +>[1]</A +></TD +><TD +ALIGN="LEFT" +VALIGN="TOP" +WIDTH="95%" +><P +>Except a RAM disk, for obvious + reasons.</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="x1532.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="c1582.html" +>Next</A +></TD +></TR +><TR +><TD +WIDTH="33%" +ALIGN="left" +VALIGN="top" +>Allocating swap space</TD +><TD +WIDTH="34%" +ALIGN="center" +VALIGN="top" +><A +HREF="c1450.html" +>Up</A +></TD +><TD +WIDTH="33%" +ALIGN="right" +VALIGN="top" +>Boots And Shutdowns</TD +></TR +></TABLE +></DIV +></BODY +></HTML +>
\ No newline at end of file |