SSD over time does get fragmented.

[tweakboy]

Since its not a mechanical moving device, there really isnt any point running a defrag. Do you defrag your RAM ? no,,,,,,,,, same thing here.

Now over time your SSD will get a little fragmented but it's NAND flash and there's no mechanical head moving back and forth to access that data so just leave it disabled.

from guru3d.com labs

 

[bryanW1995]

In more news, the sun is really REALLY hot.

 

[cmdrdredd]

In more news, the sun is really REALLY hot.

For real? I also heard that there's this stuff called water and it's everywhere and it's wet. COol huh?

 

[bryanW1995]

Speaking of water, I hope that the pool people fixed my pump today. It's really hot in Texas. Though not as hot as the sun. Usually.

 

[Coup27]

Bryan you could not have that more wrong,,,, Your pool is a lot hotter than the sun,,,, everybody knows this,, gl

 

[jhansman]

What if you spin your SSD really fast on a table? Do you have to defrag then? Inquiring minds need to know.

 

[jwilliams4200]

I think the interesting thing is that, if you COULD properly defrag an SSD, then there are almost certainly situations where a good defrag could improve read performance. This is fairly obvious, since anyone who has done SSD benchmarking knows that if you do random reads from an SSD, you get a significantly lower throughput than if you do sequential reads.

However, you cannot properly defrag an SSD, because the LBAs that are the only "visible" unit from the OS standpoint, will have little correspondence with the internal SSD flash page locations in a highly fragmented SSD.

 

[Burner27]

Tweak boy: you may find what you are looking for in this thread:

http://forums.anandtech.com/showthread.php?t=2239796&highlight=defrag+ssd

 

[groberts101]

I particularly liked this little nugget of knowledge on the quick reread.

Because of the way SSD store and access memory, it makes no difference if the file contains blocks that are right next to each or on opposite "sides" of the drive. Each access will take the same amount of time.

All I can say in regard to misinformation like that, and without getting into NDA territory, is this. Folks who make assumptions like that don't understand some of the performance enhancing functions currently being coded into firmware these days. Controllers that balance wear leveling with increased emphasis on contiguous writes to flash are some of the best performing drives on the market.

Because if randomly located data below the FTL didn't matter that much for an SSD?.. then there would be little difference from sequential to random data performance. Of course we know this is not true in the least.

Also imagine that there may just be drives on the market right this very minute that have the capability to write combine and actually create improved contiguous physical data structures by consolidating data layouts for the very sake of improving performance.

So, why would the engineers actually code the firmware to move data physically around at flash level at the cost of additional writes to nand in the process(aside from wear leveling requirements)? That's a no-brainer... because it improves efficiency and overall performance.

Not good to make blanket statements based on controller tech and knowledge aquired 4-5 years ago. Things have changed quite a bit and these new firmwares are smarter and more capable then ever before.

 

[grimpr]

I particularly liked this little nugget of knowledge on the quick reread.



All I can say in regard to misinformation like that, and without getting into NDA territory, is this. Folks who make assumptions like that don't understand some of the performance enhancing functions currently being coded into firmware these days. Controllers that balance wear leveling with increased emphasis on contiguous writes to flash are some of the best performing drives on the market.

Because if randomly located data below the FTL didn't matter that much for an SSD?.. then there would be little difference from sequential to random data performance. Of course we know this is not true in the least.

Also imagine that there may just be drives on the market right this very minute that have the capability to write combine and actually create improved contiguous physical data structures by consolidating data layouts for the very sake of improving performance.

So, why would the engineers actually code the firmware to move data physically around at flash level at the cost of additional writes to nand in the process(aside from wear leveling requirements)? That's a no-brainer... because it improves efficiency and overall performance.

Not good to make blanket statements based on controller tech and knowledge aquired 4-5 years ago. Things have changed quite a bit and these new firmwares are smarter and more capable then ever before.

Just like the new vertex 4 f/w in upping the write speed? do you recommend the v4s for a 2x128gb raid0 setup when the fw matures, cuz they are sure looking very very good.

 

[greenhawk]

What if you spin your SSD really fast on a table? Do you have to defrag then? Inquiring minds need to know.

I do not think that effects fragmentation all that much. Just a little bit like how much a egg gets scrambled by spinning it.

I suspect, like an egg, fragmentation of a SSD might be more noticable if dropped from a great height.

 

[jhansman]

I suspect, like an egg, fragmentation of a SSD might be more noticable if dropped from a great height.

I will try this with my new 830 and get back to you with the results.

 

[tulx]

Since its not a mechanical moving device, there really isnt any point running a defrag. Do you defrag your RAM ? no,,,,,,,,, same thing here.

Now over time your SSD will get a little fragmented but it's NAND flash and there's no mechanical head moving back and forth to access that data so just leave it disabled.

from guru3d.com labs

Why is your 4000th post on a tech forum about how SSD shockingly don't need to be defragmented?

 

[GrumpyMan]

Well that's not true really. I did a test and got my SSD out and hit it really hard with a hammer a bunch of times. Wow, it fragmented the data really bad. I haven't found a program to defragment my drive yet back to the way it used to be. For some reason it is just not as fast as it used to be.

 

[tweakboy]

Thanks for replys guys. Funny stuff!

I think you can run defrag app ,,,, it will finish in 10 seconds LOL ,,,,,,

I just like defragging so when I get my future SSD Im gonna defrag, I will not be able to use readyboost cuz you dont need it, its soo fast. BTW 830 gives WEI a 7.9 anyhow!
gg

Also I did say SSD needs no defragging, but I read up and actually it can become tiny bit fragmented...not even noticable.. my take on it ,,, if you will. ,,

 

[IGemini]

I'd say SSDs can be more than "a tiny bit" fragmented.

Though I'm glad to not be bothered by seeing so much red. :biggrin:

 

[groberts101]

nice!.. that's^^^.. a "near pefect" drive to run a Perfect Disk free space consolidation on.

5 bucks says that "after speeds" in ATTO go up even on that used and settled SF based drive. I tease. Mostly.

 

[Emulex]

fragments hurt ssd as well, there is logically more work to do as the o/s level if a file has 6 million fragments - might be small but still. Also recovery - good effin' luck on recovering a file with 60 fragments. I've had two ssd die on me - Both were the you touch this file and i die and stop responding (odd)- both x25-M.

I run defrag about once in a while - like restoring a backup won't kill your drive - it's alot easier to recover isht when it's not all over the place - but you have backups right?

 

[Hacp]

The only "fragmentation" that matters is deleted data with undeleted data. If your undeleted data is located in one general area, and your deleted data is segerated, the SSD performance won't be negatively affected by fragmentation.

 

[IGemini]

fragments hurt ssd as well, there is logically more work to do as the o/s level if a file has 6 million fragments - might be small but still. Also recovery - good effin' luck on recovering a file with 60 fragments. I've had two ssd die on me - Both were the you touch this file and i die and stop responding (odd)- both x25-M.

I run defrag about once in a while - like restoring a backup won't kill your drive - it's alot easier to recover isht when it's not all over the place - but you have backups right?

I'm not worried about it. ATTO and CDM still bench at spec or better than when I first set up the drive (last firmware update got better random read performance). And I don't keep anything on the SSD I'd be heartbroken to lose anyway.

 

[MagnusTheBrewer]

fragments hurt ssd as well, there is logically more work to do as the o/s level if a file has 6 million fragments - might be small but still. Also recovery - good effin' luck on recovering a file with 60 fragments. I've had two ssd die on me - Both were the you touch this file and i die and stop responding (odd)- both x25-M.

I run defrag about once in a while - like restoring a backup won't kill your drive - it's alot easier to recover isht when it's not all over the place - but you have backups right?

The bolded is incorrect. there is exactly the same amount of work being done in both cases. Accessing sectors is no faster or less work, whether they're next to each other or not in an SSD.

 

[blackangst1]

The bolded is incorrect. there is exactly the same amount of work being done in both cases. Accessing sectors is no faster or less work, whether they're next to each other or not in an SSD.

Correct. Defragging an SSD is futile and does nothing but shorten the life of the drive.

 

[Red Squirrel]

I defrag my SSD twice a day and low level format once a day. That's what my dentist told me to do.

 

[groberts101]

The bolded is incorrect. there is exactly the same amount of work being done in both cases. Accessing sectors is no faster or less work, whether they're next to each other or not in an SSD.

All I can say is.. thank god you don't write firmware code for Sandforce drives because having them slow down with incompressible data is bad enough. And the first gens throttling algorithms were some kind of sick joke. lol

The basic fact that firmware designers actually use internal optimization techniques such as.. write combining.. partial block consolidation(huh?.. the drives run "internal defrags" at the expense of small additional PE/c?.. lol).. and static data rotation often has impact on the drives consistency and overall performance just as much as it does on wear leveling/PE cycles. So, believe it or not.. some firmware actually SACRIFICES PE/c to better maintain consistent performance.

Now, why would a firmware designer actually expend additional PE/c to move data at the physical level if it had nothing to do with wear leveling? Simple answer.. optimized physical data structures on an SSD aid drive performance and stamina(consistency). Hell.. even DRAM slows down with randomly located data.

I've personally tested many SSD controllers and even have views(that I'm prevented to discuss outside of NDA) in the way that certain controllers firmware can have massive impact.. good or bad. Like.. actually "change the character of an existing controller used by many other vendors".. type of changes.

So, IMHO.. people in this thread who make blanket statements about the way that an SSD's firmware works internally are possibly reading too much outdated wikipedia?.. or simply failing to understand that firmware algorithms molded to build off or improve inherent strengths/weaknesses are used on about every SSD known to man.

These firmwares are far smarter and do far more to maintain performance than you guys give them credit for. All of which is need to maintain 85-90% of fresh install performance levels on an OS drive that's filled to 80% capacity by a user that doesn't, or even care to, understand our current firmware capabilities/limitations. Firmware is not written in stone and still has a way's to go before we reach the point that it becomes.. totally idiot proof.

 

[Cerb]

The bolded is incorrect. there is exactly the same amount of work being done in both cases. Accessing sectors is no faster or less work, whether they're next to each other or not in an SSD.

Most drives still struggle to sustain more than several thousand random IOPS, after being filled. If a <100MB file has 112,000 fragments, how is that not going to be slower, if just due to software and SATA IO overhead, than if it had 2 fragments? Then, other related files, smaller, are in the 5-20K range. Where are the non-peak IOPS?