58

Can I run Windows' defrag on an SSD drive ?

Well I believe the short answer is yes, I've heard that SSD drives require special and specific tailored defrag programs.

Is it true and, if so, where can I get it?

  • 6
    In reallity, you don't need / don't want to defrag a SSD drive... it wouldn't make your access faster, etc. – woliveirajr May 29 '13 at 12:49
  • 5
  • I think just about all of these superuser SSD fragmentation answers are wrong... at least as far as fragmented writes go. Yes, wear leveling intentionally fragments files. However, that happens in increments of the erase block size. If the minimum filesystem chunk is smaller than the erase block (almost always, and by a large factor), then a fragmented file when being written will result in many more erase blocks being rewritten. It can actually be a pretty substantial write performance hit if the chunks/clusters/inodes/etc in various erase blocks are heavily fragmented. – darron May 29 '13 at 19:55
  • And it gets much much worse with "cheap" flash storage like USB and SD: google.com/search?q=how%20to%20damage%20flash%20storage – MarcH Feb 23 '15 at 22:12
111

Since there seems to be some controversy about this I thought it would be helpful to give a detailed explanation:

You should never defrag an SSD. Don't even think about it. The reason is that physical data placement on an SSD is handled solely by the SSD's firmware, and what it reports to Windows is NOT how the data is actually stored on the SSD.

This means that the physical data placement a defragger shows in it's fancy sector chart has nothing to do with reality. The data is NOT where Windows thinks it is, and Windows has no control over where the data is actually placed.

To even out usage on its internal memory chips SSD firmware intentionally splits data up across all of the SSD's memory chips, and it also moves data around on these chips when it isn't busy reading or writing (in an attempt to even out chip usage.)

Windows never sees any of this, so if you do a defrag Windows will simply cause a whole bunch of needless I/O to the SSD and this will do nothing except decrease the useful life of the SSD.

  • 8
    @Royi Actually reading doesn't hurt an SSD, the writing does. – Little Helper May 29 '13 at 6:37
  • 54
    Furthermore, SSDs have no seek time, so there would be no performance benefit to laying out your files in consecutive blocks. – 200_success May 29 '13 at 9:04
  • 5
    @OlivierDulac: while your data is correct, conclusions are completely wrong. It's 3K cycles per cell, SSDs have advanced chips making sure to distribute writes equally over cells and prevent hotspotting. And with TLC it's even just 1000 cycles per cell. Which means that 256GB TLC SSD, with 10GB a day of writes with 3x amplification, will last 12 years. 256GB MLC SSD under same conditions will last 70 years. And even that are very conservative estimates, in real life they seem to last much, much longer anandtech.com/show/6459/… – vartec May 29 '13 at 11:34
  • 6
  • 5
    @200_success Actually, SSDs do have seek time. More specifically, SSDs read and write faster when you are use data sequentially. This person explains it much better than me: dpreview.com/forums/post/40353067 I don't know if this speed increase is because of some sort of "cache miss", because changing the address takes time, or something I can't imagine, but SSDs do have a delay for non-sequential uses. And that, to me people, means they have a seek time. – Patrick M May 29 '13 at 15:15
26

Someone (200_success) made a comment that is much more relevant to the question and it worths a better detailing.

First of all: HDD means hard disk drive, and it really has a disk inside it. This disk is divided is small pieces, called sectors, where information is stored. Take a look at this picture:

Disk image

A sector is indicated by the letter C.

Now, this sector is very small: only 512 bytes, in general. So, to store a common file of 10k, you'll need to use many sectors.

Imagine that those sectors are one following the another, like the green representation, letter D, in the picture. When you need to read the file, the hard-drive head will be positioned at the beginning of the first sector and will read all them, while the disk is spinnning.

That's how things should work.

Now it might happen to the file be spread along many sectors, each one in one part of the disk. What does that means? That to read your file again, the hard-disk head will be positioned at the beginning of the first sector, read it, then it'll have to move to the beginning of the second sector (that is somewhere else in the disk), will read it, and so on...

This will take a long time. We're talking about a physical move of the head. The more the head moves, the longer it takes.

So, you defrag the disk: the program try to moves all pieces of the file so that they end up in sequence, being easier and faster to read, since there will be less physical movement of the head to read everything.

Ok so far? So we begin to talk about SSD: they are a bunch of memory chips on a board. When you save or read something from them, the controller chip just need to activate some bits and, voilà, the correct chip is read from the memory. And it doesn't matter where it is stored, the action of accessing a memory chip is much faster than the physical move of the HDD. So, roughly speaking, you wouldn't notice that time in a fragmented file in a SDD.

And, being more detailist and correct, the controller chip will spread your file among many chips to take advantage of parallel readings and so on, so it knows how to handle your files so that they are always stored in the best (optimized about speed and wear of those memory chips) than Windows could know.

  • Fragmentation is not only a problem of the physical disk, but also of the file system managing your data. Highly fragmented files have a lot of extends/runs stored in their NTFS record, which need to be processed when you read the entire file from disk. That's not different on a SSD. – Gene May 29 '13 at 14:04
  • Defragmentation solving some minor NTFS organization issue is a different class of thing from defragmentation compensating for the performance problems due to spinning disks with moving heads. The only reason NTFS even has these extents is for the sake of spinning disks with moving heads, right? – Kaz May 29 '13 at 15:59
  • @Gene : He didn't say he's using NTFS... Yes, defrag helps performance, if you're a top-user :-). But not that astonishing result that someone had when he defrag a disk in the Win95 era. And running defrag often just to earn those .01 microseconds doesn't worth the wear. Worrying about defrag in SSD and, in few days, we'll be discussing if changing the interleave of the sectors in SSD will be worth as it was in those floppies. ;-) – woliveirajr May 29 '13 at 16:23
  • 2
    @woliveirajr - I remember changing the interleave on my HDD back in the late 1980's, and my PC's speed more than doubled. I occasionally wonder if interleave would make any difference on today's PCs. – Paddy Landau May 29 '13 at 16:51
  • @PaddyLandau :) As far as I know, all HDDs actually have no need for interleave (all sectors are read in a row, no need to set an interleave) – woliveirajr May 29 '13 at 16:57
15

The built-in defragmentation tool in Windows 8 will not defragment your SSD, but send a bunch of trim commands to the device. For more details on this, see this question. As Roberts already pointed out, you don't want to defragment your SSD at all.

  • 2
    That's cool, I wasn't aware that Windows 8 could optimize SSDs. For my Intel drive on Windows 7 you can use a program called SSD Toolbox from Intel to optimize the performance of the drive. I have never noticed that it really makes any difference though. – Tim B May 29 '13 at 12:44

Not the answer you're looking for? Browse other questions tagged or ask your own question.