Defrag SSD

[Pleb]

I read an article on defragging and they tested all of the defrag utils you can get and came to the conclusion that MyDefrag does the best job and is recommended for gamers/power users so am now using MyDefrag.

I see MyDefrag claims it can defrag SSDs safely but says to use sparingly (once per month).
Is it really OK to defrag SSD or best to not defrag SSD as many sites say?

There is another defrag util that says it can defrag SSD safely too, O&O I think.

http://www.mydefrag.com/index.html

http://www.hofmannc.de/en/windows-xp-defragmenter-test/benchmarks.html

 

[ZodaEX]

O&O dosen't defrag SSDs. It can run trim on a schedule for you if you'd like. I don't like the fact you can't do it on demand. If you want it to run trim you have to set a schedule for 1 minute in the future - you can't just run it at will. Annoying.

Honestly though modern SSDs don't need any tweaking on modern operating systems.


thessdreview.com has a great SSD optimizing guide if your jonesing to tweak it.

 

[Pleb]

I have read that site before and did pretty much all the tweaks, even turned off restore. Look at MyDefrag. It has an option that says Flash Memory Disks and if you click that it says, "This script is specially designed for Flash and SSD disks".

 

[JoeComp]

Defragmentation is not as useful for an SSD as for an HDD. There are two reasons. One is that the seek time penalty for an HDD is much greater than the latency penalty on an SSD for reading small blocks vs. a combined larger block. Second is that the defrag program cannot be certain that if it writes data to sequential LBAs that the data will actually be written to sequential pages on the SSD.

However, it is probably possible to obtain some benefit by defragmenting an SSD in cases where the SSD has a lot of fragmented, small (4K or less) blocks. Whether that benefit is worth the trouble is a question that is impossible to answer in the general case.

My advice is to note the SMART data for your SSD, then run the SSD defrag, and then examine the SMART data again to see how many erase cycles were used up by the defrag. Then use your SSD for a while and see if you notice a difference in speed. If you do, then you have to decide whether the improvement is worth the amount of erase cycles that were used up.

 

[jwcalla]

There is no need or even reason to defrag an SSD. The filesystem has no way of knowing if the file is fragmented or not on the actual disk since the disk controller specifies how the data is stored in flash. And fragmented files stored in flash memory suffer no performance penalty. So "defragmenting" an SSD would probably accomplish nothing except to perform more program / erase operations needlessly.

I also do not believe that defragging even HDDs under a modern filesystem (say, NTFS in Vista and above, ext4, HFS+) is of any value at all. These filesystems are less prone to fragmentation (sans, perhaps, very large media files where fragmentation is of no consequence).

 

[JoeComp]

And fragmented files stored in flash memory suffer no performance penalty.

Incorrect. If you compare the read speed for random vs. sequential for smaller block sizes (esp. in the range 4KiB to 128KiB), the sequential reads are faster. For 4KiB, sequential is a lot faster with most SSDs.

 

[jwcalla]

Incorrect. If you compare the read speed for random vs. sequential for smaller block sizes (esp. in the range 4KiB to 128KiB), the sequential reads are faster. For 4KiB, sequential is a lot faster with most SSDs.

But you would have to fragment a file into a bunch of smaller pieces to have any perceptible impact on retrieving that file, and the filesystem is not going to play a role in that.

 

[JoeComp]

But you would have to fragment a file into a bunch of smaller pieces to have any perceptible impact on retrieving that file, and the filesystem is not going to play a role in that.

Incorrect.

Of course the filesystem "plays a role" in how fragmented a file is. The program that creates the file, and exactly how it creates the file is also important, especially with an SSD, where if you write 4KiB now, and then wait a while and write another 4KiB to sequential LBAs, you are much less likely to get it written to sequential flash pages than if you write 8KiB all at once.

But I'm not sure why you even try to make this distinction. All the user cares about is performance. It does not matter whether the fragmentation arises primarily because of the filesystem, or because of the way a program writes a file. If the file is fragmented, the performance will be lower. It may not be noticeably lower in many cases, but that is dependent on specific details and workloads.

 

[jwcalla]

Incorrect.

Of course the filesystem "plays a role" in how fragmented a file is. The program that creates the file, and exactly how it creates the file is also important, especially with an SSD, where if you write 4KiB now, and then wait a while and write another 4KiB to sequential LBAs, you are much less likely to get it written to sequential flash pages than if you write 8KiB all at once.

But I'm not sure why you even try to make this distinction. All the user cares about is performance. It does not matter whether the fragmentation arises primarily because of the filesystem, or because of the way a program writes a file. If the file is fragmented, the performance will be lower. It may not be noticeably lower in many cases, but that is dependent on specific details and workloads.

Have there been any benchmarks that indicate performance improvement after an SSD was defragmented?

 

[FnordMan]

I also do not believe that defragging even HDDs under a modern filesystem (say, NTFS in Vista and above, ext4, HFS+) is of any value at all. These filesystems are less prone to fragmentation (sans, perhaps, very large media files where fragmentation is of no consequence).

Riiiiight. Seen a NTFS partition with moderate usage after months of no defrag? It'll be a royal mess, even if one runs vista or 7. ext3/4 i'll give you (have no personal experience with HFS or HFS+) but NTFS? Absolutely needs a defrag on a hard drive.

 

[jwcalla]

Seen a NTFS partition with moderate usage after months of no defrag?

To be honest, no. But it can't be that bad. We're in the 21st century now.

Of course when things get to be 75% capacity and up, it's going to go downhill in a hurry.

 

[zentech1]

Do not defrag an SSD. As eluded to above, with the internal wear leveling algorithms of modern SSD controllers defrag programs have no clue if the end result will be less fragmentation or not. I would not defrag an SSD unless you just want to burn some write cycles up. As long as you have Trim you should be good to go.

 

[Pleb]

I also do not believe that defragging even HDDs under a modern filesystem (say, NTFS in Vista and above, ext4, HFS+) is of any value at all. These filesystems are less prone to fragmentation (sans, perhaps, very large media files where fragmentation is of no consequence).

Yea, I remeber a guy in a HDD group on Usenet who always proclaimed on a modern OS and modern HDD you never need to defrag. That url I posted with tests done says otherwise though so I use MyDefrag anyway.

 

[Pleb]

Do not defrag an SSD. As eluded to above, with the internal wear leveling algorithms of modern SSD controllers defrag programs have no clue if the end result will be less fragmentation or not. I would not defrag an SSD unless you just want to burn some write cycles up. As long as you have Trim you should be good to go.

In MyDefrag it does say to use on SSD sparingly, no more than once per month. That is how often I defgrag a standard HDD though so will use it less than that on SSD or not all.

 

[ZodaEX]

Old habits die hard

 

[evilsofa]

Apparently, Microsoft got tired of being asked why Windows Defragmentation was turned off for SSDs, so with Windows 8, they have renamed "Windows 7 Defragmentation Scheduling" to "Optimize Drive". When the user asks Windows 8 to optimize a drive and the drive is an SSD, it simply sends the TRIM command.

When the question of whether an SSD should be defragmented comes up, the proper response is to ask if it is understood what TRIM does, and if it is not understood, then explain it.

The methods that worked for optimizing a HDD's data do not apply to SSDs because everything about SSDs is completely different. You defrag a HDD, and TRIM an SSD. You would not defrag an SSD any more than you would TRIM an HDD; both are ridiculously wrong and completely missing the point of how they operate on a basic level.

 

[JoeComp]

Actually, it is certainly true that it is possible for an SSD to get into a state where TRIM cannot improve the performance, but certain specialized SSD defragmenting techniques (not necessarily the same algorithms used to defrag HDDs) could improve the performance.

This is obvious if you consider two facts. One is that small block sequential reads are faster than small block random reads for the vast majority of SSDs. Second is that if you write a largish block of data to an SSD to sequential LBAs, all at once, it is highly likely that it will be written mostly or wholly sequentially to flash pages.

As I said before, it is impossible to tell, in general, whether a particular user's SSD is in a sufficiently fragmented state that doing a special SSD defrag would result in a noticeable increase in performance. My guess is that it is probably rare for a typical consumer to have an SSD get into a state where an SSD defrag run would produce a noticeable increase in performance. Most consumers should not even worry about it.

But it is incorrect to say that running a special SSD defrag is always a bad idea. There are undeniably cases where a defrag algorithm designed for SSDs could be of benefit.

 

[kanecvl]

I dont the think defragging the ssd is beneficial. I would advise against the defrag until there is proof that it is helpful.

 

[LeftSide]

This argument is really quite ridiculous. The SSD controller acts like a hard drive to the OS, but there is a very large layer of extraction where the SSD internally maps blocks to wherever it wants. The OS has absolutely no idea where the actual blocks are. How can you defrag something that you have no idea where the actual data is? If you can answer that simple question then you win the argument. The problem is, every drive manufacture, controller card, and firmware, choose where and when to write data differently. These layers are never exposed to the OS, and it's quite impossible to know where the data is. If you don't have access to the low level mappings of the information how could you possible organize it.

 

[JoeComp]

The OS has absolutely no idea where the actual blocks are.

Incorrect.

Obviously the filesystem does not know the exact mapping between LBAs and flash memory pages. However, it is incorrect to say that the defrag program has "absolutely no idea" how sequential blocks are likely to be when they are written in a certain way.

If you write 512KiB to an SSD with sequential LBAs, all at once, it is a good bet that most or all of it will end up in sequential flash pages (or interleaved in a way that makes it equivalent to sequential flash pages when read). It is a very good bet that it will NOT end up in 4KiB chunks randomly distributed across the flash memory.

Therefore, if you have128 4KiB blocks on your SSD at random LBAs (and that were written widely spaced in time so that they are likely random in flash as well), then if you collect them together into sequential LBAs and write them back all at once, there is an excellent chance that the result will be mostly or wholly sequential in flash. As a result, performance is very likely to improve in such a case (how often the SSD gets into such a state, and whether the performance improvement is noticeable is another question).

The reason you are confused is because you are insisting on certainty, which you have with an HDD, but you do not have with an SSD. But certainty is not required in order to have a good chance of improving the sequential nature of data in flash pages -- all that is required is to write in largish chunks and for the SSD to frequently (but not necessarily always) translate that to sequential flash pages.

 

[bigdogchris]

I read an article on defragging and they tested all of the defrag utils you can get and came to the conclusion that MyDefrag does the best job and is recommended for gamers/power users so am now using MyDefrag.

I see MyDefrag claims it can defrag SSDs safely but says to use sparingly (once per month).
Is it really OK to defrag SSD or best to not defrag SSD as many sites say?

There is another defrag util that says it can defrag SSD safely too, O&O I think.

http://www.mydefrag.com/index.html

http://www.hofmannc.de/en/windows-xp-defragmenter-test/benchmarks.html

Considering SSD's wear leveling will move blocks around (fragmenting data), isn't defragging it for any reason (none of which are legitimate) a little counter productive?

Windows turns off defraggmentation on SSD's for a reason. If for some reason you have the urge to press analyze disk and see the fragmentation on an SSD, you're a glutton for punishment.

 

[ob1]

If you are able to get an SSD in such a bad fragmented way that it impacts performance noticeably, I submit to you that a secure erase then format would be the best corrective action in that case over defrag. Also if you continue to get into those use cases, your usage patterns should be examined and tweaked to prevent that from happening. Let the SSD manage itself and hopefully the OS will eventually catch up and stop treating all drives like mechanical drives.

 

[Brahmzy]

Sizable over-provisioning is the single best thing you can do for your SSD performance/health.

 

[ZodaEX]

Sizable over-provisioning is the single best thing you can do for your SSD performance/health.

Wrong, aligning your partition is more important than over-provisioning.

 

[Brahmzy]

Wrong, aligning your partition is more important than over-provisioning.

Idiot. They are aligned to begin with, with a proper operating system. Understood. Why bring up an issue of yesteryear?

 

[Brahmzy]

Sorry, response was a little harsh. But with that train of thought, ya might as well include making sure your OS has trim, making sure your 6G SSD isn't plugged into a 3G port etc. etc.

 

[ZodaEX]

Idiot. They are aligned to begin with, with a proper operating system. Understood.

It is presumptuous to assume that everyone who runs an SSD is also running a modern O.S. When I got my first and second SSD I was still running windows XP, which does not align your partition to begin with. I'm not an idiot for understanding that there are still Windows XP users out there who may have different needs than I do.

 

[Neb]

In an age where XP's EOL date is coming fairly shortly, I can definitely see Brahmzy's point...however slightly harshly written

 

[Brahmzy]

I've been running SSDs in any number of ways for almost 7 years now. Way early adopter. I forget there's still folks getting into them now.

 

[jwcalla]

Incorrect.

Obviously the filesystem does not know the exact mapping between LBAs and flash memory pages. However, it is incorrect to say that the defrag program has "absolutely no idea" how sequential blocks are likely to be when they are written in a certain way.

But that's not really what he said. The statement he made that you quoted and labeled "incorrect" was actually 100%, absolutely correct.

 

[JoeComp]

But that's not really what he said. The statement he made that you quoted and labeled "incorrect" was actually 100%, absolutely correct.

Wrong again.

The OS/filesystem/writing program does have some idea "where the actual blocks are" if it has written them in a certain way. It does not know exactly, but it does know that they are very likely mostly or wholly sequential if they were written together to sequential LBAs.

Look, this is not a difficult concept. If you put a deck of cards in order and then cut it a couple times and then deal out some cards, it is incorrect to say that you have "absolutely no idea" about the cards that will come out. You know that they will come out mostly in order.

 

[Meeho]

What about after a million cuts?

 

[jwcalla]

Wrong again.

The OS/filesystem/writing program does have some idea "where the actual blocks are" if it has written them in a certain way. It does not know exactly, but it does know that they are very likely mostly or wholly sequential if they were written together to sequential LBAs.

Look, this is not a difficult concept. If you put a deck of cards in order and then cut it a couple times and then deal out some cards, it is incorrect to say that you have "absolutely no idea" about the cards that will come out. You know that they will come out mostly in order.

And again, that's not what he said. I'm not going to argue it much with you but it would be extraordinarily difficult if not impossible to look at the filesystem table and from that be able to determine where data is written on the disk and whether or not it is fragmented.

And even with a large file sequential write there is no guarantee -- or even a "very likely mostly" guarantee -- that the data will be stored contiguous. It completely depends on the available capacity and the controller's wear leveling algorithm.

But we do seem to agree that there is no solid data that shows defragging an SSD produces any sort of perceptible performance difference, but does likely waste P/E cycles. So the argument is somewhat moot anyway.

 

[Neb]

And again, that's not what he said. I'm not going to argue it much with you but it would be extraordinarily difficult if not impossible to look at the filesystem table and from that be able to determine where data is written on the disk and whether or not it is fragmented.

And even with a large file sequential write there is no guarantee -- or even a "very likely mostly" guarantee -- that the data will be stored contiguous. It completely depends on the available capacity and the controller's wear leveling algorithm.

But we do seem to agree that there is no solid data that shows defragging an SSD produces any sort of perceptible performance difference, but does likely waste P/E cycles. So the argument is somewhat moot anyway.

Agreed. Once the file system passes it to the ssd's controller, all bets are off. There's just no guarantee of any sort where your data is going or even where it'll end up later because there simply isn't any sort of transparency of that level to the OS. Of course, the whole certainty aspect was talked about earlier. It'd take a significant amount of testing in order to figure out whether telling the OS to move the files together would actually affect a benefit and at what cost, especially since ssd chipsets often vary quite a bit in how they optimize.

 

[LeftSide]

Incorrect.

Obviously the filesystem does not know the exact mapping between LBAs and flash memory pages. However, it is incorrect to say that the defrag program has "absolutely no idea" how sequential blocks are likely to be when they are written in a certain way.

If you write 512KiB to an SSD with sequential LBAs, all at once, it is a good bet that most or all of it will end up in sequential flash pages (or interleaved in a way that makes it equivalent to sequential flash pages when read). It is a very good bet that it will NOT end up in 4KiB chunks randomly distributed across the flash memory.

Therefore, if you have128 4KiB blocks on your SSD at random LBAs (and that were written widely spaced in time so that they are likely random in flash as well), then if you collect them together into sequential LBAs and write them back all at once, there is an excellent chance that the result will be mostly or wholly sequential in flash. As a result, performance is very likely to improve in such a case (how often the SSD gets into such a state, and whether the performance improvement is noticeable is another question).

The reason you are confused is because you are insisting on certainty, which you have with an HDD, but you do not have with an SSD. But certainty is not required in order to have a good chance of improving the sequential nature of data in flash pages -- all that is required is to write in largish chunks and for the SSD to frequently (but not necessarily always) translate that to sequential flash pages.

Joe,
If you really think that large sequential writes stay together in an SSD then I should just stop arguing with you. Maybe and I mean maybe when the drive is brand new and all the flash cells have 0 wear you could be correct. Buy any drive over 1 year old will not work that way. Writes are spread out to reduce wear. Stagnant data is moved to flash that has more wear. The way the drive writes also depends on free space, and the type of data. There are so many variables that making any type of statement is a pure guess. The only thing we know for sure is that we don't know anything, and the manufacturer tells us not to defrag.
I would love for you to prove me wrong. The only issue is, you're going to have to prove me wrong scientifically on every firmware, size, and manufacture. All evidence so far on every person who is familiar with SSD's say not to defrag, and that there is a layer of extraction that we cannot get past.

 

[LeftSide]

The more I think about this the more ludicrous it becomes. After a heavy write session (defrag) most SSDs will immediately start their trim cleanup, and optimization algorithms.

 

[JoeComp]

Joe,
If you really think that large sequential writes stay together in an SSD then I should just stop arguing with you.

You should stop arguing, and start trying to educate yourself. I'm not sure why you are so confused, I have clearly explained how SSDs work.

Do you really think that an SSD, which has 512KiB or larger erase blocks, is going to frequently split up sequential flash pages in the range 128KiB to 512KiB or larger? If so, you really need to learn more about how SSDs and flash memory works.

 

[JoeComp]

Agreed. Once the file system passes it to the ssd's controller, all bets are off. There's just no guarantee of any sort where your data is going or even where it'll end up later because there simply isn't any sort of transparency of that level to the OS. Of course, the whole certainty aspect was talked about earlier. It'd take a significant amount of testing in order to figure out whether telling the OS to move the files together would actually affect a benefit and at what cost, especially since ssd chipsets often vary quite a bit in how they optimize.

First of all, you are not making sense when talking about "the OS". What was being discussed in this thread is a defrag program with an algorithm tailored for SSDs.

Second, you are wrong that it would take a "significant amount of testing in order to figure out" how most SSDs usually behave when given a largish block of data to write to sequential LBAs.

If you really think that an SSD -- when provided with 512KiB of data to write all at once to sequential LBAs -- will frequently split that data up into 4KiB or 8KiB random flash pages, then you have a lot to learn about how SSDs and flash memory works.

 

[JoeComp]

And again, that's not what he said.

And again you are wrong.

In the context of this discussion, it is completely incorrect to state that the defrag program has "absolutely no idea where the actual blocks are" when they are written in a certain way. If they are written all at once, to sequential LBAs, then the defrag program has an excellent idea of where they are: mostly or wholly sequential flash pages.

 

[JoeComp]

What about after a million cuts?

Time for another defrag. But that would be a very long time.