Bonehead Mistake! Defrag'd SSD....

[Cjr60611 31]

Hello All

 

Just realized my desktop has been defragging my SSD that contains the majority of my FSX files and ALL of my add-on's (except REX).  Been noticing some stutters that I hadn't been getting before and started to troubleshoot when I realized my mistake.  Think it happened twice, at the most...

 

Stutter problems seemed to start when I downloaded a scenery add-on but maybe the result of the Windows 7 defrag process???

 

So, the question I have is; can the defrag process cause stuttering?  If so, is there a away to fix?

 

Or, am I faced with having to scrap the SSD (reformat) and start from scratch? Not really sure what the implication is of that.  Obviously, that is last resort.

 

*Note: going to upgrade my cpu from i5-4670k to i7-4790k in a few days (please don't try to talk me out of it).  Do you think it's best to upgrade first and see what happens or, run the fix (whatever it maybe) on the SSD first?  

 

I know there are quite a few members with tons of experience that may have some advice.  Thanks in advance...

[BeechPapa 32]

Defragmenting an SSD won't cause a performance loss. No need to worry. You're not supposed to defrag SSDs because of the random way the controller writes data to the NANDs.  There is no benefit to organizing and regrouping the data together like an HDD where physical location of the data on disk matters. So because there is no performance benefit to defragging an SSD, and since it reduces the ultimate life of the NAND by increasing read and write cycles, the net result of defragmenting is harmful to the SSD over the long term. The harm done to the NAND during the read/writes cannot be undone with reformatting and/or secure erase, but most SSDs can withstand enough read/writes that it probably won't even matter. You're more likely to replace the SSD with a larger capacity or faster one before the fail point anyway. Basically, stop defragging your SSDs... but don't give it any more thought or worry than that.      

[MartinRex007 390]

Use the software that should of come with your SSD to optimize it, I have an Intel SSD and run the optimizing software once a week as recommended by Intel.

 

Cheers

Martin

[Cjr60611 31]

Defragmenting an SSD won't cause a performance loss. No need to worry. You're not supposed to defrag SSDs because of the random way the controller writes data to the NANDs.  There is no benefit to organizing and regrouping the data together like an HDD where physical location of the data on disk matters. So because there is no performance benefit to defragging an SSD, and since it reduces the ultimate life of the NAND by increasing read and write cycles, the net result of defragmenting is harmful to the SSD over the long term. The harm done to the NAND during the read/writes cannot be undone with reformatting and/or secure erase, but most SSDs can withstand enough read/writes that it probably won't even matter. You're more likely to replace the SSD with a larger capacity or faster one before the fail point anyway. Basically, stop defragging your SSDs... but don't give it any more thought or worry than that.      

Thanks, BeechPapa - Good to know I didn't totally screw the SSD up!

Use the software that should of come with your SSD to optimize it, I have an Intel SSD and run the optimizing software once a week as recommended by Intel.

 

Cheers

Martin

Hey Martin

 

Good point!  I have a Samsung SSD, don't think I still have the disc it came with but I'm going to check the web to see if there is an optimizing program out there!

 

Thanks for the advice!

[lownslo 592]

Samsung Magician can manage your SSD.  Find it here: http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/support/downloads.html

 

HTH

 

Greg

[W2DR 1,859]

Here are some numbers from a couple of optimization runs on a Samsung 849EVO done a couple of months ago with Samsung Magician. Amazing difference:

 

Sequential Read (MB/s) Before=544 After=5476

Sequential Write (MB/s) Before=524 After=4800

 

Random Read (IOPS) Before=74039 After=179093

Random Writes (IOPS) Before=76511 After=138472

 

Doug

[ryanbatc 12,820]

5476? Sure that's not 547.6? Didn't think any ssd could be that fast

 

Edit: never mind I'm thinking of a different bench

[Luke 782]

Here are some numbers from a couple of optimization runs on a Samsung 849EVO done a couple of months ago with Samsung Magician. Amazing difference:

 

Sequential Read (MB/s) Before=544 After=5476

Sequential Write (MB/s) Before=524 After=4800

 

 

SATA3 is limited to 6 gigabits a second, or 600MB/s. Both "after" numbers are exceeding the limits of the interface by almost a factor of 10, so I would assume the numbers are either incorrect or merely exercising the RAM cache.

 

Cheers!

 

Luke

[W2DR 1,859]

SATA3 is limited to 6 gigabits a second, or 600MB/s. Both "after" numbers are exceeding the limits of the interface by almost a factor of 10, so I would assume the numbers are either incorrect or merely exercising the RAM cache.

 

Cheers!

 

Luke

Well, shite. I thought it was a bit too good to be true...and it was. I'm going back to my Velociraptors. Even old folks like me can understand that technology. Thanks Luke.

 

Doug

[Luke 782]

Well, shite. I thought it was a bit too good to be true...and it was. I'm going back to my Velociraptors. Even old folks like me can understand that technology. Thanks Luke.

 

Doug

 

Don't be so hard on yourself.

 

Fundamentally, they're very similar. You have a block storage device connected via a SATA3 interface. The fact that the Velociraptor is a spinning bit of rusted metal is an implementation detail that software (and I suspect the OS) isn't really aware of. Its only major impact is that random access is MUCH faster on the SSD, and sequential access is actually a little faster on the HD.

 

In both cases, Windows has a cache in front of the drive. It's exponentially faster to read commonly accessed items from RAM than disk, so every operating system made in the past 25 years or so devotes all the free RAM it can to disk cache.

 

If the benchmarking software isn't careful, it could just exercise the cache - which explains really high numbers. But again, that can happen no matter what drive you're using.

 

SSD "optimization" software can be useful for older drives and/or operating systems that don't support TRIM. For the Samsung 840 EVOs, they had a number of issues that would cause blocks written a long time ago to be re-read much more slowly than recently written blocks, but if you're running the latest drive firmware (and you should) then Samsung Magician shouldn't be needed - the drive is silently rewriting old blocks in the background.

 

Cheers!

 

Luke

[W2DR 1,859]

Don't be so hard on yourself.

 

Fundamentally, they're very similar. You have a block storage device connected via a SATA3 interface. The fact that the Velociraptor is a spinning bit of rusted metal is an implementation detail that software (and I suspect the OS) isn't really aware of. Its only major impact is that random access is MUCH faster on the SSD, and sequential access is actually a little faster on the HD.

 

In both cases, Windows has a cache in front of the drive. It's exponentially faster to read commonly accessed items from RAM than disk, so every operating system made in the past 25 years or so devotes all the free RAM it can to disk cache.

 

If the benchmarking software isn't careful, it could just exercise the cache - which explains really high numbers. But again, that can happen no matter what drive you're using.

 

SSD "optimization" software can be useful for older drives and/or operating systems that don't support TRIM. For the Samsung 840 EVOs, they had a number of issues that would cause blocks written a long time ago to be re-read much more slowly than recently written blocks, but if you're running the latest drive firmware (and you should) then Samsung Magician shouldn't be needed - the drive is silently rewriting old blocks in the background.

 

Cheers!

 

Luke

Great explanation Luke. I've done a bit more research this morning and now realize that, as you say, there is no need to ever optimize my SSD's. I've learned more about TRIM, IOPS, NANDs, and various types of cache than I thought I'd ever want to know. But I've found it's really fascinating stuff once you get the basics down. Thanks again for setting me out on this trail. I think I've really learned something.

 

Doug