SSD -> Defragmentation Schedule

[jaquith]

The answer may surprise many folks, and some won't be surprised.

 

[COLGeek]

The answer may surprise many folks, and some won't be surprised.

Since the THG community an an informed community and since all true geeks know that you shouldn't defrag SSDs, this doesn't surprise me.

 

[randomizer]

Poll fixed. Don't forget to add an expiration date or it closes immediately.

Since the THG community an an informed community and since all true geeks know that you shouldn't defrag SSDs, this doesn't surprise me.

I'm not going to be surprised by the poll results, but only because I know that most people only have a limited understanding of disk fragmentation and how it affects SSDs.

 

[jaquith]

^ Thanks! - I was running background tasks while creating it, and I saw it entered - 30 days.
Obviously, ANS is Never. Helpful "Tip." BTW - Windows 7 recognizes SSD and automatically disables Defragmentation of SSD drives.

 

[randomizer]

The answer is "never" if you use the GUI-based defragmentation utility. The command-line defragmenter has an option that is quite useful for SSDs (the /X command-line argument; ie "defrag /X c:"). This consolidates free space on the drive.

 

[jaquith]

There's no difference with an SSD to access any part of any memory chips, oddly {some} SSD "seem" to get faster with age - http://www.tomshardware.com/reviews/windows-7-ssd-trim,2705-16.html Therefore, leave 'em be. Unfortunately for us humans bladder control is all that seems to get faster with age.

Worst, current technology the SSD have a limited Write lifespan. Where's HAL when you need his holographic memory - probably in our lifetime.

 

[randomizer]

Yes, it is true that access time is not an issue. That is why there is no point doing file defragmentation (ie. trying to make files contiguous). But if a drive has, say 15-20% remaining free space, what guarantee do we have that this free space is entirely made up of empty blocks? It is almost certain that many blocks contain less than 512kB of data, but this means that to fill them up they must first be erased and reprogrammed. If the majority of the remaining free space exists due to partially-filled blocks, the SSD will read fast but write slow. TRIM does absolutely nothing to prevent this, only idle-time garbage collection can improve the situation unless the user intervenes and some SSD controllers have pretty poor garbage collection (looking at you Marvell).

Thus in some instances it can be beneficial to consolidate free space, but not individual files. With free space consolidation we are not interested in whether or not a file is contiguous, only that free space is made up of as many completely empty blocks as possible. If a drive gets alot of idle time while powered on, or it doesn't get regularly filled without also deleting data, this is likely to be a non-issue because the controller will perform some consolidation on its own. If a drive is used regularly and alot of data gets "overwritten" but not deleted, you may run into some issues with write speeds at a very inconvenient time. Removing unneeded data and consolidating free space before writing logical 1s all over that free space essentially performs garbage collection using an on-demand, brute force method. Yes it increases writes on the drive, but the SSD controller would do exactly the same thing given enough time.

It is quite likely that this will be entirely unnecessary in the future.

 

[jaquith]

^ Interesting - I need to do some research with Pros & Cons. However, if true then the controller technology and management needs some real improvement. On our server side we still aren't ready to jump on-board until some the cost, issues and technology matures. Till then SAS + RAID.