Defraging explained

I don't think I need to ask you not to plagiarise my answer for your assignment. It'll be available on google quickly and easily in about 2 minutes anyway. Use it as a guide. If there is anything you've missed, adapt your assignment to discuss it. You could always cite an entire paragraph, if you know how. That's the way I used to do my assignments ;). Keep in mind, though, lockergnome may only be considered about as accurate as wikipedia.

The problem of fragmentation can be likened to trying to find a parallel parking space large enough to fit your car. Filling the side of the road full of parked cars is easy enough. Now imagine 2 random cars leave their space and drive off. The total size of these two spaces would otherwise permit a truck to be parked, but the cars weren't parked next to each other, so the spaces aren't joined. Defragmenting is the task of moving the spaces to the very end.

The above analogy gives great justice to one cause of file fragmentation, but there's another cause that can't easily be likened to anything else. Files can grow in size. Imagine that the cars could grow in size, while they're parked in their spaces. A huge problem, yeh? You'd get cars growing into each other! Well, unlike cars, files can be split into fragments. If a file grows and there is no free space immediately following it, the OS will create a new fragment for the growth somewhere else on the drive. Likewise, files can (but rarely do) shrink. This causes a similar problem to the previous topic of cars leaving noncontiguous free spaces (free spaces that aren't next to each other).

So what's the problem with that? Well, hard drives use mechanical motors to jump to locations on the platter, where it reads the data from. If a file is contiguous (all the parts are next to each other), the hard drive doesn't have to work so hard to retrieve the entire file. If parts are scattered all over the drive, you can imagine the drive will have to work a lot harder to reassemble the file. Some people believe solid state drives are unaffected by file fragmentation. Not long ago I was banned from #chris for attempting to educate someone about the effects of file fragmentation on SSDs. Consider a drive that is 90% full with a series of small free-space fragments scattered making up the 10% free space. Now consider what happens when the drive attempts to fill 5% of that free space with a single, large file. Write speed is affected. This is a fairly uninformed and optimistic conclusion compared to reality. Solid state drives write in blocks of 512KB to 1MB, which means every time you write even 1 byte to an SSD, your drive controller has to read the destination block from the flash chips, put the information in and then write the destination block back to the flash chips. Before the information can be rewritten to the flash chips, the block must be erased from the flash chips (unless it's already been erased by TRIM). Most files won't end right on the boundary of these blocks, so each block ends up being a read-erase-write cycle just to write data to the drive. Many will attempt to use TRIM as defense for this, but TRIM can only work optimally when a file being truncated or deleted entirely uses an entire flash block. If the file doesn't use an entire flash block, the problem still exists.