WEBVTT - How does disk defragmentation work?

0:00:00.520 --> 0:00:03.840
<v Speaker 1>Welcome to Brainstuff from how stuff works dot com where

0:00:03.840 --> 0:00:14.840
<v Speaker 1>smart Happens. Hi, I'm Marshall Brain with today's question, how

0:00:14.880 --> 0:00:20.200
<v Speaker 1>does disk defrag work? The word disk defrag is typically

0:00:20.320 --> 0:00:23.880
<v Speaker 1>used to refer to the Microsoft Windows utility called the

0:00:23.960 --> 0:00:27.760
<v Speaker 1>disk defragment or. It's designed to solve a problem that

0:00:27.760 --> 0:00:31.280
<v Speaker 1>occurs because of the way hard disk store data. If

0:00:31.320 --> 0:00:34.680
<v Speaker 1>you've read the article how hard disks work, then you

0:00:34.800 --> 0:00:39.320
<v Speaker 1>know three key facts about hard disks. First, hard disk

0:00:39.400 --> 0:00:42.760
<v Speaker 1>store data in chunks called sectors. If you imagine the

0:00:42.800 --> 0:00:45.600
<v Speaker 1>surface of the disc divided into rings like the rings

0:00:45.600 --> 0:00:48.760
<v Speaker 1>of a tree, and then imagine dividing each ring into

0:00:48.800 --> 0:00:53.040
<v Speaker 1>pie slices, a sector is one pie slice on one ring.

0:00:53.600 --> 0:00:56.800
<v Speaker 1>Each sector holds a fixed amount of data, like five

0:00:57.160 --> 0:01:00.840
<v Speaker 1>and twelve bytes. The hard disk has a small arm

0:01:00.960 --> 0:01:03.360
<v Speaker 1>that can move from ring to ring on the surface

0:01:03.360 --> 0:01:06.559
<v Speaker 1>of the disk to reach a particular sector. The hard

0:01:06.640 --> 0:01:08.840
<v Speaker 1>disc moves the arm to the right ring, and then

0:01:08.840 --> 0:01:12.520
<v Speaker 1>it waits for the sector to spin into position. Third,

0:01:12.640 --> 0:01:15.959
<v Speaker 1>hard discs are slow in computer terms compared to the

0:01:16.000 --> 0:01:18.360
<v Speaker 1>speed of the processor in its memory. The time it

0:01:18.440 --> 0:01:20.680
<v Speaker 1>takes for the arm to move and for a sector

0:01:20.720 --> 0:01:24.160
<v Speaker 1>to spin into place is an eon. Because of fact

0:01:24.200 --> 0:01:27.760
<v Speaker 1>number three, you want to minimize ARM movement as much

0:01:27.800 --> 0:01:31.720
<v Speaker 1>as possible, and you want data stored in sequential segments

0:01:31.760 --> 0:01:34.600
<v Speaker 1>on the disc. So let's imagine that you install a

0:01:34.600 --> 0:01:38.000
<v Speaker 1>new application on an empty hard disk. Because the disk

0:01:38.160 --> 0:01:40.440
<v Speaker 1>is empty, the computer can store the files of the

0:01:40.440 --> 0:01:44.959
<v Speaker 1>application into sequential sectors on sequential rings. This is an

0:01:44.959 --> 0:01:48.120
<v Speaker 1>efficient way to place data on a hard disk. As

0:01:48.160 --> 0:01:51.880
<v Speaker 1>you use the disc. However, this efficient technique becomes harder

0:01:51.920 --> 0:01:54.800
<v Speaker 1>for a disk. What happens is that the disc fills

0:01:54.920 --> 0:01:58.760
<v Speaker 1>up and then you erase files to reclaim space. Those

0:01:58.760 --> 0:02:01.840
<v Speaker 1>files that you delete are scattered all over the surface

0:02:01.880 --> 0:02:04.680
<v Speaker 1>of the disk. When you load a new application or

0:02:04.720 --> 0:02:07.280
<v Speaker 1>a large file onto the disc, it ends up being

0:02:07.320 --> 0:02:12.320
<v Speaker 1>stored in hundreds or thousands of these scattered pockets of space. Now,

0:02:12.400 --> 0:02:15.600
<v Speaker 1>when the computer tries to load the scattered pieces the

0:02:15.680 --> 0:02:18.400
<v Speaker 1>discs ARM has to move all over the surface and

0:02:18.440 --> 0:02:22.560
<v Speaker 1>it takes forever. The idea behind the disc defragment or

0:02:22.639 --> 0:02:25.320
<v Speaker 1>is to move all the files around so that every

0:02:25.360 --> 0:02:29.120
<v Speaker 1>file is stored on sequential sectors on sequential rings on

0:02:29.200 --> 0:02:33.119
<v Speaker 1>the disc. In addition, a good disk defragment or may

0:02:33.200 --> 0:02:36.840
<v Speaker 1>also try to optimize things even more, for example, by

0:02:36.880 --> 0:02:40.520
<v Speaker 1>placing all applications close to the operating system on the

0:02:40.560 --> 0:02:44.880
<v Speaker 1>disc to minimize movement when an application loads. When done

0:02:44.960 --> 0:02:49.760
<v Speaker 1>well on older discs, defragmenting can significantly increase the speed

0:02:49.800 --> 0:02:52.880
<v Speaker 1>of file loading. On a new disc that's never filled

0:02:52.960 --> 0:02:56.240
<v Speaker 1>up or had any significant number of file deletions, it

0:02:56.280 --> 0:02:59.680
<v Speaker 1>will have almost no effect because everything is stored sequentially

0:02:59.720 --> 0:03:03.560
<v Speaker 1>all ready. As you might imagine, the process of individually

0:03:03.639 --> 0:03:06.799
<v Speaker 1>picking up and moving thousands of files on a relatively

0:03:06.800 --> 0:03:10.720
<v Speaker 1>slow hard disk is not a quick process. It normally

0:03:10.760 --> 0:03:15.240
<v Speaker 1>takes hours for the defragment or to run properly, ensure

0:03:15.320 --> 0:03:19.360
<v Speaker 1>that you have no other applications running, and then run

0:03:19.400 --> 0:03:22.920
<v Speaker 1>the defragment or sometime late in the evening before you

0:03:22.960 --> 0:03:25.000
<v Speaker 1>plan to go to sleep, or before you go out

0:03:25.040 --> 0:03:27.400
<v Speaker 1>to dinner or something, so it has a big chunk

0:03:27.440 --> 0:03:30.919
<v Speaker 1>of time to do its job. For more on this

0:03:31.120 --> 0:03:33.600
<v Speaker 1>and thousands of other topics, is it how staff works

0:03:33.639 --> 0:03:38.120
<v Speaker 1>dot com