• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

defragging an SSD

NeghVar

NeghVar

2[H]4U
Joined
May 1, 2003
Messages
2,685
I know its sacrilegious to defrag a SSD, but I would like to know if there is any scenario that could validate defragging it. I have recently begun receiving the message “insufficient system resources exist to complete the requested service” within about 30 minutes after booting up when I try to run just about any application. Task manager shows plenty of memory and no apps pulling large amounts of CPU cycles or memory. While searching the internet, I have come across numerous responses stating that the OS drive may be severely fragmented. I ran defraggler and found that my OS drive (a SSD) is 76% fragmented. Would it be safe to do a defrag only once to see what the results are?
 
also, I have Windows 7 pro 64-bit, SSD is in AHCI mode, I tried optimize which only decreased the fragmentation by 1%
 
1. How much free space is on your SSD?
2. Windows defrag is pretty sucky.
3. Use MyDefrag to defrag it. You will probably have to run 3-4 times at least to get it fully defragmented. http://www.mydefrag.com/

4. Before defragging it:
a. Disable the swap file (don't reboot yet) - re-enable after defragging, but set it to manual size of 2 or 4GB.
b. Run a drive cleanup - Select the "cleanup system files button" in the disk cleanup wizard. Make sure you have everything selected so it will get rid of all it can. Then reboot so it can do the Windows update cleanup.
c. Delete all files it will let you out of C:\Windows\Temp and C:\Windows\Prefetch
d. Delete the Windows update cache: http://rahuldpatel.wordpress.com/2008/12/02/clearing-windows-update-cache-upon-update-failure/
e. Disable hibernate (admin command prompt and then type in - powercfg -h off - and then hit enter)
You can re-enable it after defragging if you want... but pretty pointless with an SSD.
f. Disable System Restore (If you want to re-enable it after defragging, go ahead.. but it is a waste of space IMO)
g. Under your drive properties disable "Allow files on this drive to have contents indexed in addition to file properties" - Windows indexing still sucks and can cause all sorts of issues when it becomes corrupt.

As for defragging an SSD, I defrag mine every once in a while. I am surprised you are not having more trouble with the drive being 76% fragmented.

No matter the drive, sequential reads are faster than random. On SSDs this might have more to do with the file system than it does with the drive itself.. but it is still true.
 
No, never defrag an SSD. All you're doing is moving data from one memory chip to another and exhausting your writes on the SSD. I have no idea what you were searching for, but check your kernel memory numbers in the task manager.

For SSDs fragmentation doesn't matter as SSDs can access data at the same speed no matter where it's located due to the fact that it's all memory. Standard HDDs suffer with fragmentation as it's easier for the spindle to read the data when it's grouped together rather than when it's spread out all over the drive.
 
+1 to never defrag an SSD..... Just stahp.

You probably need to adjust your page file. Ultimately you could have a corrupted Windows install.

Work on that before thinking about your SSD...
 
+1 no defrag.

As stated you are just shortening the life of your SSD.
 
Those of you that say never defrag, are you blindly stating that because thats what they say, or are their studies you know of that prove there is no practical or theoretical reason or scenario that would validate defragging an SSD.

before this, I also ran chkdsk, sfc /scannow, ccleaner and a full scan with IO advanced systemcare ultimate. No problems with chkdsk or sfc. Standard clean up of registry from IO. Don't immediately start blaming IO advanced systemcare ultimate. I've been using it for over a year on this system and these problem started last week.

System memory:8GB
open space on SSD: 58GB

Honestly, how detrimental would a single defrag of a SSD be on its lifespan? year? month? day? hour?...nanosecond? Or will it cause a chain-reaction that will shatter the space/time continuum and destroy the universe.
 
Last edited:
Ultima99 said:
http://www.oo-software.com/en/docs/whitepaper/ood_ssd.pdf

There, a company that sells defragmentation software telling you not to do it.

Your desperate theory of "they are lying to me about defragging SSD's" flies in the face of why write/wear leveling was invented in the first place.

You have another issue causing your problem. Time to move on.
Click to expand...

Show me where in my posts that I said anything about anyone lying about defragging an SSD. I asked for is a source of absolute assurance from a person or company that likely knows everything to know about SSDs. The link you posted would be enough. There is no need to attempt to start a flame war.
 
At the end of the day, we don't need to prove there is anything bad about defragging an SSD. You need to prove there is some benefit. There isn't. Defrag moves stuff closer together to reduce/eliminate latency. This is not a an issue for an SSD, so unless you can come up with a credible reason for doing so...
 
danswartz said:
At the end of the day, we don't need to prove there is anything bad about defragging an SSD. You need to prove there is some benefit. There isn't. Defrag moves stuff closer together to reduce/eliminate latency. This is not a an issue for an SSD, so unless you can come up with a credible reason for doing so...
Click to expand...

I have run tests before/after defragging and SSD.

Boot time and program load times are quicker after running a defrag on a severely fragmented SSD.

Alos, go look for yourself on benchmarks for SSDs. You can very easily see that sequential reads and writes are still faster than random reads and writes.

I have also personally seen where defragmenting an SSD (just like defragmenting a HDD) can fix issues in Windows that Windows starts having because the drive is too fragmented.

This is from managing around 100 desktops, laptops, and workstations running
Windows 7 x64 and a few running Windows 7 32-bit.

When fragmentation gets too high, Windows starts having random problems... slowness, programs crashing, file errors, etc.

Time and time again, defragmenting has proven to help fix these type of issues when nothing else is wrong with the system.

Plus, defragmenting an SSD every once in a while is not going to reduce the life of an SSD very much at all... For the general user.. maybe they will get only 9 instead of 10 years out of an SSD. By that time, it would have been replaced anyway.

In the past 3.5 years, I have had a total of 1 SSD die.. and that was a controller failure, not a media failure.
 
Sorry, but I've got to disagree. The way that the hardware is designed there's simply no difference between "fragmentation" and "non-fragmentation." The controller simply maps NAND cells to pages to memory blocks which it then presents however it wants to windows as logical sectors.

Saying that "defragging SSDs" speeds things up is akin to saying that defragging whatever is in your RAM will speed things up, it's accessed in similar ways. When you say sequential reads you're referring to something file-system level, not disk level. Sequential reads can be hurt by fragmentation with traditional spinning disks due to the fact that the head reading the data would have to be moved to a different part of the disk which would require another spin of the disk to access. It's similar to a record player, if your data is all defragged then it simply has to keep reading along the disk. If it's fragmented then the head has to go all over the platter to get the data it needs, requiring the disk to spin around before it can get to what it needs. This is called "seeking" and you can see the average seek times on HDD specifications.

This is not an issue with SSDs, they can access whatever data that they want whenever they want, there's no mechanical parts moving, the controller just reads the memory address in. The firmware/controller of the SSD handles the balancing and loading of its memory how it decides, all windows sees is what is presented to it by the firmware/controller.
 
Last edited:
Pylor said:
Sorry, but I've got to disagree. The way that the hardware is designed there's simply no difference between "fragmentation" and "non-fragmentation." The controller simply maps NAND cells to pages to memory blocks which it then presents however it wants to windows as logical sectors.

Saying that "defragging SSDs" speeds things up is akin to saying that defragging whatever is in your RAM will speed things up, it's accessed in similar ways. When you say sequential reads you're referring to something file-system level, not disk level. Sequential reads can be hurt by fragmentation with traditional spinning disks due to the fact that the head reading the data would have to be moved to a different part of the disk which would require another spin of the disk to access. It's similar to a record player, if your data is all defragged then it simply has to keep reading along the disk. If it's fragmented then the head has to go all over the platter to get the data it needs, requiring the disk to spin around before it can get to what it needs. This is called "seeking" and you can see the average seek times on HDD specifications.

This is not an issue with SSDs, they can access whatever data that they want whenever they want, there's no mechanical parts moving, the controller just reads the memory address in. The firmware/controller of the SSD handles the balancing and loading of its memory how it decides, all windows sees is what is presented to it by the firmware/controller.
Click to expand...

Then it is at the file system level that is slowing it down. If the Windows file system sees the file as fragmented, then it is going to be doing extra read commands as well as address translation in order to get the information it wants. When it sees stuff as sequential, it will read the data in larger blocks.

The same goes for SSDs and RAM. Having data in sequential memory blocks is faster to read from and write to then having parts of the data scattered all over the place. when you have to do extra calculations to get and/or write the data, it is going to slow it down.
 
NeghVar said:
Those of you that say never defrag, are you blindly stating that because thats what they say, or are their studies you know of that prove there is no practical or theoretical reason or scenario that would validate defragging an SSD.

before this, I also ran chkdsk, sfc /scannow, ccleaner and a full scan with IO advanced systemcare ultimate. No problems with chkdsk or sfc. Standard clean up of registry from IO. Don't immediately start blaming IO advanced systemcare ultimate. I've been using it for over a year on this system and these problem started last week.

System memory:8GB
open space on SSD: 58GB

Honestly, how detrimental would a single defrag of a SSD be on its lifespan? year? month? day? hour?...nanosecond? Or will it cause a chain-reaction that will shatter the space/time continuum and destroy the universe.
Click to expand...

Hi, NeghVar,

Here's a link addressing the question regarding defragmenting a SSD from the Crucial.com SSD Knowledge Base: Does defragmenting an SSD cause any long term performance loss when using Windows 7?

The answer is provided by a Crucial Mod so it should carry some weight.

Hope this helps.
 
cyclone3d said:
The same goes for SSDs and RAM. Having data in sequential memory blocks is faster to read from and write to then having parts of the data scattered all over the place. when you have to do extra calculations to get and/or write the data, it is going to slow it down.
Click to expand...

Calculations? Everything I've ever known was the virtual address space which allows the following:
A program can use a contiguous range of virtual addresses to access a large memory buffer that is not contiguous in physical memory.
Click to expand...

It's also the same thing that allows memory to be paged out to the HDD (page file). There's no real calculations done.
 
Pylor said:
Calculations? Everything I've ever known was the virtual address space which allows the following:

It's also the same thing that allows memory to be paged out to the HDD (page file). There's no real calculations done.
Click to expand...

There has to be some calculation/translation done at some point. whether it be RAM, HDD, SDD, etc, you have to deal with latency when reading from or writing to non-contiguous addresses.

With contiguous blocks, you can read larger blocks in one go. When you have data spread across multiple smaller blocks, there are going to be more I/O cycles used.

Sure you can map to virtual address space... but that doesn't make the physical addresses become contiguous.
 
cyclone3d said:
There has to be some calculation/translation done at some point. whether it be RAM, HDD, SDD, etc, you have to deal with latency when reading from or writing to non-contiguous addresses.

With contiguous blocks, you can read larger blocks in one go. When you have data spread across multiple smaller blocks, there are going to be more I/O cycles used.

Sure you can map to virtual address space... but that doesn't make the physical addresses become contiguous.
Click to expand...

That's the point though isn't it? Translation is always done, regardless of whether the physical memory is contiguous or not. That's just how the operating system works, through the virtual address space. Whether the physical memory locations are sequential or not doesn't matter, the processor looks up every bit it requires from the virtual address space. I mean, it's the very definition of random access memory

RAM is considered "random access" because you can access any memory cell directly if you know the row and column that intersect at that cell.
The opposite of RAM is serial access memory (SAM). SAM stores data as a series of memory cells that can only be accessed sequentially (like a cassette tape).
Click to expand...


When you're talking about sequential file transfer you're confusing many layers of computing topology. Random accesses are generally small in size and are usually limited by IOPS on SSDs while they're limited by seek times on HDDs (this is one of the reasons why SSDs are so much faster as OS drives), while sequential accesses tend to be larger (think transfering a movie). For HDD (as said before) the head has to read the data from a spinning disk. If the file is fragmented (spread across the platter of the disk) then the head has to move around and wait for that part of the disk to spin across where it's located again. This is the seek time and why defragging hard drives is good, it reduces seek times by clumping the files together on the disk so that the head can just read it in quicker due to being able to read the data associated with the file by reading during the entire cycle of the spindle spinning. In a fragmented HDD, the head would have to move during the cycle of the spindle and would not be as efficient in terms of reading for as much of the cycle.

I'm not opposed to discussing this further, if I'm wrong then I'm wrong, but please start posting credible sites/references for what you're saying.
 
Last edited:
And for large files, it would actually be better for it to be fragmented across the SSD. The SSD controller has channels, and the channels have set bandwidths. SSDs are able to get extremely high sequential transfers because they parallelize transferring of the file (think multi-threading). That's also why random reads/writes are so much slower than sequential, because you can't transfer a small file over multiple channels, it's extremely inefficient to do so. Think multi-threading overhead vs just one thread... at one point, the overhead becomes so high relative to the workload that just running it on one core is faster.
 
Pylor said:
That's the point though isn't it? Translation is always done, regardless of whether the physical memory is contiguous or not. That's just how the operating system works, through the virtual address space. Whether the physical memory locations are sequential or not doesn't matter, the processor looks up every bit it requires from the virtual address space. I mean, it's the very definition of random access memory




When you're talking about sequential file transfer you're confusing many layers of computing topology. Random accesses are generally small in size and are usually limited by IOPS on SSDs while they're limited by seek times on HDDs (this is one of the reasons why SSDs are so much faster as OS drives), while sequential accesses tend to be larger (think transfering a movie). For HDD (as said before) the head has to read the data from a spinning disk. If the file is fragmented (spread across the platter of the disk) then the head has to move around and wait for that part of the disk to spin across where it's located again. This is the seek time and why defragging hard drives is good, it reduces seek times by clumping the files together on the disk so that the head can just read it in quicker due to being able to read the data associated with the file by reading during the entire cycle of the spindle spinning. In a fragmented HDD, the head would have to move during the cycle of the spindle and would not be as efficient in terms of reading for as much of the cycle.

I'm not opposed to discussing this further, if I'm wrong then I'm wrong, but please start posting credible sites/references for what you're saying.
Click to expand...

Ok, I am going to run a very thorough test and see the results. Right now I am running Fragger on one of my 120GB SSDs. I first copied all the data off of it and then formatted it before starting Fragger.

It has been running for a few hours creating an extremely fragmented drive. Looks like it maxes out at 100,500 files total. So far it has written a little over 2GB of data to the drive.

Once it stops.... hope it detects when the drive is full, I will then delete enough of the files to give me 10% free space.

I will then do a bit for bit image of the drive so I can easily recreate the initial fragmented file system.

Then I will do a file copy test to another SSD that has been formatted and see what the results are.

I will also do a copy from a clean SSD to the fragmented SSD to see what the speeds are.

Then I will wipe both SSDs again and do a copy test again to/from the test SSD to see what the speeds are.

This test may not get finished until middle of next week... but I will post screenshots, etc.

Of course this is still not going to recreate the problems that Windows has with extremely fragmented drives.. but it should give me an idea of the speed difference.

I also found an article where somebody ran fragger on a drive and then ran benchmarks on the drive... It showed a 10% slowdown when fragmented vs defragmented.
http://www.pcworld.com/article/2047513/fragging-wonderful-the-truth-about-defragging-your-ssd.html

I don't totally agree with them... but then again they did not frag a boot drive either.

I've just seen way too many systems that Windows has issues on when the boot SSD is fragmented where defragging it fixes the issues to think otherwise.
 
A defragmented filesystem is always better than a fragmented one for a homogeneous block device. There is zero advantage to a fragemented file. For the host it means it has to read more metadata blocks and not before these reads are complete, the corresponding data blocks can be read.

On the other hand, an SSD is not a homogeneous block device. It has internal fragementation that can not be determined by the end user. If by defragmentation of the filesystem the underlying block device gets more fragmented, the result can decrease the performance. IMHO, if there is enough free space on the SSD (means internal overprovisioning + external overprovisioning + trimmed space), large sequential writes should end up in a optimized pattern on NAND. I don't know how recent defragmenters work, but if they move the data in small chunks instead, it may not be the best for the SSD.

Tsumi said:
And for large files, it would actually be better for it to be fragmented across the SSD. The SSD controller has channels, and the channels have set bandwidths. SSDs are able to get extremely high sequential transfers because they parallelize transferring of the file (think multi-threading). That's also why random reads/writes are so much slower than sequential, because you can't transfer a small file over multiple channels, it's extremely inefficient to do so. Think multi-threading overhead vs just one thread... at one point, the overhead becomes so high relative to the workload that just running it on one core is faster.
Click to expand...

The SSD controller does this striping automatically even for consecutive space. It is not like the first NAND is filled, then the second one is filled, and so on.
 
@cyclone3d..

You need to learn about how SSD's work. Unlike Hard Drives, there is no read or write latency caused by "distance" as there is with a hard drive. Packing or reorganizing data to reduce "distance" between consecutive data locations has no meaning with SSD's. Sure there can be lots of r/w latency with a SSD, but it's not caused by data's physical locations on the NAND. All data locations on an SSD are "logical" in location, not "physical" as they are on a hard drive, so when you get a report in the OS that the SSD has been "optimized" after a defrag, it means nothing. The SSD has done nothing more than move data around (wasting write cycles), and modified it's tracking tables to better match what the OS wants to "think" is a better structure, but in reality is not.

Think of it as a new stupid manager in charge of a warehouse. Having to justify his position, he tells the warehouse foreman he wants stuff reorganized for efficiency in a particular manner but is barred from actually entering the warehouse because management is not allowed into these hazardous work areas. The foreman actually having worked the warehouse for years, actually knows what works and what doesn't simply changes puts a moves a couple of boxes and changes his paperwork around to suit the demands of his new stupid boss without actually rearranging the warehouse and tells his boss it has been "defragmented and optimized" as per the stupid boss's request. Life goes on with the stupid manager being none the wiser..

You're being the stupid manager.


@NeghVar
I work in SSD R&D. You're wasting your time defragmenting SSD's. Unlike others though I hope you continue to waste the write cycles of your SSD's for no good purpose because it means you will have to buy another sooner which keeps me employed!
 
Last edited:
Wow this topic again.

Cyclone3d isn't wrong. However I think he overstates the benefit of defragging an SSD.

More I/O calls are required to read/write non-consecutive LBAs on a block device and this is a constant regardless of how the block device physically stores data. That being said SSD can process more IOPS than a HDD can usually by several orders of magnitude.

In order for you to see major degradation from fragmentation on an SSD such fragmentation would have to be much closer to pathological than on an HDD. Modern filesystems try very hard to avoid pathological fragmentation.

A non-fragmented file will read faster on an SSD (or any block device) than a fragmented file. The difference depends on the physical device and the degree of fragmentation. In the case of an SSD fragmentation is generally not worth worrying about.
 
devman said:
Wow this topic again.

Cyclone3d isn't wrong. However I think he overstates the benefit of defragging an SSD.

More I/O calls are required to read/write non-consecutive LBAs on a block device and this is a constant regardless of how the block device physically stores data. That being said SSD can process more IOPS than a HDD can usually by several orders of magnitude.
Click to expand...

Not to mention the benchmarks that i've seen that show that SSDs do better under moderate queue depths than under shallow ones. (more IOPS vs. only a few)
 
There is no doubt that an SSD can be fragmented. The question is, does it have an effect ? That will depend on the SSD, but it will never be really bad like it was on HDDs.

The other question being, can it be defragmented ? And there the answer is no, at least not with anything other than a manufacturer provided tool. By running a generic defragmenter it's possible to get some benefit, but it's also possible to make it worse, there is no way to know.

What can be done is an image with a file level software (Acronis True Image for example), files in that image will not be fragmented. Then secure erase the SSD and restore the image on it.

I'm still 100% confident that fragmentation has nothing to do with the OP problem.
 
Hi, NeghVar,

Have you checked the Win7 Event Viewer to see what the Event ID is for the "insufficient system resources ..." error and then researched that ID in the MS Knowledge Base?

Have downloaded the August MS updates and then had this problem arise? If so, have you tried rolling back to a restore point before the August updates?
 
FnordMan said:
Not to mention the benchmarks that i've seen that show that SSDs do better under moderate queue depths than under shallow ones. (more IOPS vs. only a few)
Click to expand...

Queue depth is based on workload though, not file location on the SSD.
 
Aesma said:
There is no doubt that an SSD can be fragmented. The question is, does it have an effect ? That will depend on the SSD, but it will never be really bad like it was on HDDs.

The other question being, can it be defragmented ? And there the answer is no, at least not with anything other than a manufacturer provided tool. By running a generic defragmenter it's possible to get some benefit, but it's also possible to make it worse, there is no way to know.

What can be done is an image with a file level software (Acronis True Image for example), files in that image will not be fragmented. Then secure erase the SSD and restore the image on it.

I'm still 100% confident that fragmentation has nothing to do with the OP problem.
Click to expand...

For clarity, fragmentation as referred to in this thread (at least by me) is related to fragmentation as reportable by the operating system. A fragmented file being defined as a file which has contents in non-consecutive LBAs.

The relationship of LBA to physical layout is unknowable in the general sense, though inferences can be made given context around how the file was written and nature of the device.

Any block device can be defragmented, it is only a question of does it make a real-world difference. My opinion is fragmentation will generally not hurt throughput on SSD in real-world situations and so defragging them is unnecessary. That doesn't mean one cannot construct scenarios where an reading a file from SSD will be slower due to pathological fragmentation.
 
Last edited:
Aesma said:
I'm still 100% confident that fragmentation has nothing to do with the OP problem.
Click to expand...
THIS.

I for one have NEVER seen an issue get resolved because of a defrag....

Chuklr said:
Hi, NeghVar,

Have you checked the Win7 Event Viewer to see what the Event ID is for the "insufficient system resources ..." error and then researched that ID in the MS Knowledge Base?

Have downloaded the August MS updates and then had this problem arise? If so, have you tried rolling back to a restore point before the August updates?
Click to expand...
^^^Thanks for getting the thread back on track to actual troubleshooting.

Like, I said, It's a Windows issue. Lets do some basic troubleshooting first before we start blaming an SSD. Which, BTW, in my experience either work perfectly, or don't work at all.

OP, do all this and report back.
 
Warrior said:
THIS.

I for one have NEVER seen an issue get resolved because of a defrag....


^^^Thanks for getting the thread back on track to actual troubleshooting.

Like, I said, It's a Windows issue. Lets do some basic troubleshooting first before we start blaming an SSD. Which, BTW, in my experience either work perfectly, or don't work at all.

OP, do all this and report back.
Click to expand...

Hi, Warrior,

You're welcome! :D

Unfortunately I doubt it will do much good.
 
You must log in or register to reply here.
Back
Top