summaryrefslogtreecommitdiff
path: root/sag-0.6.1-www/sag-0.6.1.html/x747.html
blob: 1efe4a4b159fcaf2f699a602a286292e09b4d72e (plain)
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
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
<!DOCTYPE HTML PUBLIC "-//Norman Walsh//DTD DocBook HTML 1.0//EN">
<HTML
><HEAD
><TITLE
>Hard disks</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="Using Disks and Other Storage Media"
HREF="c701.html"><LINK
REL="NEXT"
TITLE="Floppies"
HREF="x787.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="c701.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="x787.html"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN747"
>Hard disks</A
></H1
><P
>This subsection introduces terminology related to hard
	disks.	If you already know the terms and concepts, you can skip
	this subsection.</P
><P
>See <A
HREF="x747.html#HD-SCHEMATIC"
>Figure 4-1</A
> for a schematic picture
	of the important parts in a hard disk.	A hard disk consists of
	one or more circular <I
CLASS="GLOSSTERM"
>platters</I
>,
	
		<A
NAME="AEN753"
HREF="#FTN.AEN753"
>[1]</A
>
		
	of which either or both <I
CLASS="GLOSSTERM"
>surfaces</I
> are coated
	with a magnetic substance used for recording the data.	For each
	surface, there is a <I
CLASS="GLOSSTERM"
>read-write head</I
> that
	examines or alters the recorded data.  The platters rotate on
	a common axis; a typical rotation speed is 3600 rotations per
	minute, although high-performance hard disks have higher speeds.
	The heads move along the radius of the platters; this movement
	combined with the rotation of the platters allows the head to
	access all parts of the surfaces.</P
><P
>The processor (CPU) and the actual disk communicate through
	a <I
CLASS="GLOSSTERM"
>disk controller</I
>.  This relieves the rest of the computer
	from knowing how to use the drive, since the controllers for
	different types of disks can be made to use the same interface
	towards the rest of the computer.  Therefore, the computer can
	say just ``hey disk, gimme what I want'', instead of a long and
	complex series of electric signals to move the head to the proper
	location and waiting for the correct position to come under
	the head and doing all the other unpleasant stuff necessary.
	(In reality, the interface to the controller is still complex,
	but much less so than it would otherwise be.)  The controller
	can also do some other stuff, such as caching, or automatic bad
	sector replacement.</P
><P
>The above is usually all one needs to understand about the
	hardware.  There is also a bunch of other stuff, such as the
	motor that rotates the platters and moves the heads, and the
	electronics that control the operation of the mechanical
	parts, but that is mostly not relevant for understanding the
	working principle of a hard disk.</P
><P
>The surfaces are usually divided into concentric rings,
	called <I
CLASS="GLOSSTERM"
>tracks</I
>, and these in turn are
	divided into <I
CLASS="GLOSSTERM"
>sectors</I
>.  This division
	is used to specify locations on the hard disk and to allocate
	disk space to files.  To find a given place on the hard disk,
	one might say ``surface 3, track 5, sector 7''.  Usually the
	number of sectors is the same for all tracks, but some hard disks
	put more sectors in outer tracks (all sectors are of the same
	physical size, so more of them fit in the longer outer tracks).
	Typically, a sector will hold 512 bytes of data.  The disk itself
	can't handle smaller amounts of data than one sector.</P
><DIV
CLASS="FIGURE"
><P
><B
><A
NAME="HD-SCHEMATIC"
>Figure 4-1. A schematic picture of a hard disk.</A
></B
></P
><P
><IMG
SRC="hd-schematic.gif"></P
></DIV
><P
>Each surface is divided into tracks (and sectors) in
	the same way.  This means that when the head for one surface
	is on a track, the heads for the other surfaces are also on
	the corresponding tracks.  All the corresponding tracks taken
	together are called a <I
CLASS="GLOSSTERM"
>cylinder</I
>.	It takes
	time to move the heads from one track (cylinder) to another,
	so by placing the data that is often accessed together (say, a
	file) so that it is within one cylinder, it is not necessary to
	move the heads to read all of it.  This improves performance.
	It is not always possible to place files like this; files
	that are stored in several places on the disk are called
	<I
CLASS="GLOSSTERM"
>fragmented</I
>.</P
><P
>The number of surfaces (or heads, which is the same thing),
	cylinders, and sectors vary a lot; the specification of the
	number of each is called the <I
CLASS="GLOSSTERM"
>geometry</I
> of a hard disk.  The
	geometry is usually stored in a special, battery-powered memory
	location called the <I
CLASS="GLOSSTERM"
>CMOS RAM</I
>, from where the operating
	system can fetch it during bootup or driver initialization.</P
><P
>Unfortunately, the BIOS
	
		<A
NAME="AEN773"
HREF="#FTN.AEN773"
>[2]</A
>
		
	has a design limitation, which makes it
	impossible to specify a track number that is larger than 1024 in
	the CMOS RAM,
	which is too little for a large hard disk.  To overcome this,
	the hard disk controller lies about the geometry, and 
	<I
CLASS="GLOSSTERM"
>translates the addresses</I
> given by the computer into something
	that fits reality.  For example, a hard disk might have 8 heads,
	2048 tracks, and 35 sectors per track.
	
		<A
NAME="AEN776"
HREF="#FTN.AEN776"
>[3]</A
>
		
	Its controller could lie to the computer and claim that it
	has 16 heads, 1024 tracks, and 35 sectors per track, thus not
	exceeding the limit on tracks, and translates the address that
	the computer gives it by halving the head number, and doubling
	the track number.  The math can be more complicated in reality,
	because the numbers are not as nice as here (but again, the
	details are not relevant for understanding the principle).
	This translation distorts the operating system's view of how
	the disk is organized, thus making it impractical to use the
	all-data-on-one-cylinder trick to boost performance.</P
><P
>The translation is only a problem for IDE disks.	SCSI disks
	use a sequential sector number (i.e., the controller translates
	a sequential sector number to a head, cylinder, and sector
	triplet), and a completely different method for the CPU to talk
	with the controller, so they are insulated from the problem.
	Note, however, that the computer might not know the real geometry
	of an SCSI disk either.</P
><P
>Since Linux often will not know the real geometry of a disk,
	its filesystems don't even try to keep files within a single
	cylinder.  Instead, it tries to assign sequentially numbered
	sectors to files, which almost always gives similar performance.
	The issue is further complicated by on-controller caches, and
	automatic prefetches done by the controller.</P
><P
>Each hard disk is represented by a separate device
	file.  There can (usually) be only two or four IDE hard
	disks.	These are known as <TT
CLASS="FILENAME"
>/dev/hda</TT
>,
	<TT
CLASS="FILENAME"
>/dev/hdb</TT
>, <TT
CLASS="FILENAME"
>/dev/hdc</TT
>,
	and <TT
CLASS="FILENAME"
>/dev/hdd</TT
>, respectively.  SCSI
	hard disks are known as <TT
CLASS="FILENAME"
>/dev/sda</TT
>,
	<TT
CLASS="FILENAME"
>/dev/sdb</TT
>, and so on.  Similar naming
	conventions exist for other hard disk types; see XXX (device
	list) for more information.  Note that the device files for
	the hard disks give access to the entire disk, with no regard
	to partitions (which will be discussed below), and it's easy to
	mess up the partitions or the data in them if you aren't careful.
	The disks' device files are usually used only to get access to the
	master boot record (which will also be discussed below).</P
></DIV
><H3
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN753"
HREF="x747.html#AEN753"
>[1]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>The platters are made of a hard
		substance, e.g., aluminium, which gives the hard disk
		its name.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN773"
HREF="x747.html#AEN773"
>[2]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>The BIOS is some built-in software stored on
		ROM chips.  It takes care, among other things, of the
		initial stages of booting.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN776"
HREF="x747.html#AEN776"
>[3]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>The numbers are completely
		imaginary.</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="c701.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="x787.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Using Disks and Other Storage Media</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="c701.html"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Floppies</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>