diff options
Diffstat (limited to 'sag-0.6.1-www/Invisible/sag-0.6/node65.html')
| -rw-r--r-- | sag-0.6.1-www/Invisible/sag-0.6/node65.html | 125 |
1 files changed, 125 insertions, 0 deletions
diff --git a/sag-0.6.1-www/Invisible/sag-0.6/node65.html b/sag-0.6.1-www/Invisible/sag-0.6/node65.html new file mode 100644 index 0000000..15f0462 --- /dev/null +++ b/sag-0.6.1-www/Invisible/sag-0.6/node65.html @@ -0,0 +1,125 @@ +<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> +<!--Converted with LaTeX2HTML 96.1-h (September 30, 1996) by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds --> +<HTML> +<HEAD> +<TITLE>The buffer cache</TITLE> +<META NAME="description" CONTENT="The buffer cache"> +<META NAME="keywords" CONTENT="sag"> +<META NAME="resource-type" CONTENT="document"> +<META NAME="distribution" CONTENT="global"> +<LINK REL=STYLESHEET HREF="sag.css"> +</HEAD> +<BODY LANG="EN" > + <A NAME="tex2html1128" HREF="node66.html"><IMG WIDTH=37 HEIGHT=24 ALIGN=BOTTOM ALT="next" SRC="./next_motif.gif"></A> <A NAME="tex2html1126" HREF="node59.html"><IMG WIDTH=26 HEIGHT=24 ALIGN=BOTTOM ALT="up" SRC="./up_motif.gif"></A> <A NAME="tex2html1122" HREF="node64.html"><IMG WIDTH=63 HEIGHT=24 ALIGN=BOTTOM ALT="previous" SRC="./previous_motif.gif"></A> <A NAME="tex2html1130" HREF="node1.html"><IMG WIDTH=65 HEIGHT=24 ALIGN=BOTTOM ALT="contents" SRC="./contents_motif.gif"></A> <A NAME="tex2html1131" HREF="node114.html"><IMG WIDTH=43 HEIGHT=24 ALIGN=BOTTOM ALT="index" SRC="./index_motif.gif"></A> <BR> +<B> Next:</B> <A NAME="tex2html1129" HREF="node66.html">Boots And Shutdowns</A> +<B>Up:</B> <A NAME="tex2html1127" HREF="node59.html">Memory Management</A> +<B> Previous:</B> <A NAME="tex2html1123" HREF="node64.html">Allocating swap space</A> +<BR> <P> +<H1><A NAME="SECTION00660000000000000000">The buffer cache</A></H1> +<P> +<A NAME="secbuffercache"> </A> +<P> + Reading from a disk<A NAME="tex2html28" HREF="footnode.html#1869"><IMG ALIGN=BOTTOM ALT="gif" SRC="./foot_motif.gif"></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 <tt>ls</tt><A NAME="1928"> </A> 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 <b>disk buffering</b>, and the memory used for the + purpose is called the <b>buffer cache</b>. +<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> + 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> + 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 <b>write-through</b>: the data is written + to disk at once (it is kept in the cache as well, + of course). The cache is called <b>write-back</b> + 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> + Because of this, you should never turn off the + power without using a proper shutdown procedure (see chapter + <A HREF="node66.html#chboothalt">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 <tt>sync</tt><A NAME="1934"> </A> command <b>flushes</b> + 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 <tt>update</tt><A NAME="1937"> </A> + running in the background which does a <tt>sync</tt><A NAME="1939"> </A> + every 30 seconds, so it is usually not necessary + to use <tt>sync</tt><A NAME="1941"> </A>. Linux has an additional daemon, + <tt>bdflush</tt><A NAME="1943"> </A>, which does a more imperfect sync more + frequently to avoid the sudden freeze due to heavy disk + I/O that <tt>sync</tt><A NAME="1945"> </A> sometimes causes. +<P> + Under Linux, <tt>bdflush</tt><A NAME="1947"> </A> is started by <tt>update</tt><A NAME="1949"> </A>. There is + usually no reason to worry about it, but if <tt>bdflush</tt><A NAME="1951"> </A> happens + to die for some reason, the kernel will warn about this, and you + should start it by hand (<tt>/sbin/update</tt><A NAME="1953"> </A>). +<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> + 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> + 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> + 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> +<HR><A NAME="tex2html1128" HREF="node66.html"><IMG WIDTH=37 HEIGHT=24 ALIGN=BOTTOM ALT="next" SRC="./next_motif.gif"></A> <A NAME="tex2html1126" HREF="node59.html"><IMG WIDTH=26 HEIGHT=24 ALIGN=BOTTOM ALT="up" SRC="./up_motif.gif"></A> <A NAME="tex2html1122" HREF="node64.html"><IMG WIDTH=63 HEIGHT=24 ALIGN=BOTTOM ALT="previous" SRC="./previous_motif.gif"></A> <A NAME="tex2html1130" HREF="node1.html"><IMG WIDTH=65 HEIGHT=24 ALIGN=BOTTOM ALT="contents" SRC="./contents_motif.gif"></A> <A NAME="tex2html1131" HREF="node114.html"><IMG WIDTH=43 HEIGHT=24 ALIGN=BOTTOM ALT="index" SRC="./index_motif.gif"></A> <BR> +<B> Next:</B> <A NAME="tex2html1129" HREF="node66.html">Boots And Shutdowns</A> +<B>Up:</B> <A NAME="tex2html1127" HREF="node59.html">Memory Management</A> +<B> Previous:</B> <A NAME="tex2html1123" HREF="node64.html">Allocating swap space</A> +<P><ADDRESS> +<I>Lars Wirzenius <BR> +Sat Nov 15 02:32:11 EET 1997</I> +</ADDRESS> +</BODY> +</HTML> |