1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
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>
|
