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
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
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
>
|
