Main Area and Open Discussion > Living Room

Never Defragment an SSD ?

(1/3) > >>

Armando:
I found that article interesting. The author, Jan Goyvaerts, is the developer behind "Just Great Software" (RegexBuddy, EditPad, etc.) -- he also wrote several great books.

f0dder:
I'm not sure he's entirely correct in saying the following:
Reading adjacent blocks of data is no faster than reading blocks that are spread out over the drive. Fragmentation does not affect SSD drive speed.
--- End quote ---
If you look at benchmarks, all the SSDs have different speed characteristics when dealing with linear reads/writes compared to scattered smaller I/O. It can matter a lot for writes, but also matters for reads.

I agree fully that defragmenting SSDs is a bad idea, because of the limited amount of erase-cycles of the flash cells. It might make sense to defragment individual files if they're heavily fragmented; you'd do that by moving the file to another drive (on a mechanical disk, prefarably), then moving it back to the SSD (using a tool that tries to allocate the entire chunk contiguously).

Also, I see a guy in the comments recommending a single defrag after you installed all your apps. Don't do that - if you want the SSD defragged, start by installing to a mechanical disk, defrag that, and move the install to the SSD using, for instance, Paragon Virtualization Manager.

Similarly, if your SSD ends up heavily fragmented, create a disk image of it to a mechanical drive, defrag that image, do a single-pass wipe of the SSD (to let the drive know all sectors blocks are blank, useful for the reallocation algorithms), then transfer the defragged image back.

MerleOne:
Some people are apparently working on improving this : http://flashfire.org/xe/

Stoic Joker:
Also, I see a guy in the comments recommending a single defrag after you installed all your apps. Don't do that - if you want the SSD defragged, start by installing to a mechanical disk, defrag that, and move the install to the SSD using, for instance, Paragon Virtualization Manager.

Similarly, if your SSD ends up heavily fragmented, create a disk image of it to a mechanical drive, defrag that image, do a single-pass wipe of the SSD (to let the drive know all sectors blocks are blank, useful for the reallocation algorithms), then transfer the defragged image back.-f0dder (February 17, 2011, 04:12 AM)
--- End quote ---

Now granted I haven't gotten into the SSD thing yet, but... Given this:
Modern SSDs even lie to the operating system. If the operating system tells the drive to save a file in blocks 728, 729, and 730, the drive may decide to write it to blocks 17, 7829, and 78918 instead, if it determines that those blocks haven’t been worn out as much yet. The drive keeps a lookup table of all its blocks, so that when the OS wants to read blocks 728 through 730, the drive reads blocks 17, 7829, and 78918. With such drives, defragmentation software can’t possibly work. The software will think and tell the user that file X was nicely defragmented and stored in blocks 728, 729, and 730, while it actually has no idea where the data is stored physically on the drive.-From the Article
--- End quote ---

So apposed to what is normally (IDE/SCSI/SATA) perceived as a defrag. - accounting for the hardware lieing - Wouldn't that really just be somewhere between damage control and a placebo effect?

CWuestefeld:
If you look at benchmarks, all the SSDs have different speed characteristics when dealing with linear reads/writes compared to scattered smaller I/O. It can matter a lot for writes, but also matters for reads.
-f0dder (February 17, 2011, 04:12 AM)
--- End quote ---

That's true. But I think that the scales are different. Disc blocks are relatively big. We're not talking about defragging at the byte scale. Even if a file has hundreds of fragments, it's not going to make any noticeable (or probably even measurable) difference in the overall access times.

Navigation

[0] Message Index

[#] Next page