Should i defregment ssd ?

[life24]

Hi,
Should i defregment ssd ? i need?

 

[alzan]

No.

If you OS is Windows 7 or greater the OS will run the TRIM utility on the SSD.

 

[tweakboy]

You cant defrag a SSD drive. You cant and wont be let to defraging . you dont defrag a SSD drive,, they dont need it.

 

[life24]

No.

If you OS is Windows 7 or greater the OS will run the TRIM utility on the SSD.

Why not do this?

 

[alzan]

Why not do this?

As I understand it, SSD's have high but limited read/write operations; defragmenting will render your SSD useless before it's normal usage lifespan.

See this thread for more detailed answers: http://forums.anandtech.com/showthread.php?t=2069761

 

[dave_the_nerd]

SSDs are not addressed linearly like HDDs, the controller writes to new flash and recycles old flash as needed, and abstracts it from the system's perspective. (Your computer doesn't know precisely which pages on the flash contain what data.)

So even if you could defrag it, you'd just be undoing all the work the controller does wrt wear leveling and performance optimization.

 

[aviator79]

You got it. SSDs got limited write cycles. Defrag costs write cycle since the data has to be "moved" around. In contrary to conventional HDDs which must move the reading arm to the data" (acess time), SSDs do not need to, the can read every different data block at the same short time. So in fact, it is better if the SSD is fragmented (If it has multiple lanes) because the data may lay on different physical chips and can be accessed parallel.

 

[life24]

SSDs are not addressed linearly like HDDs, the controller writes to new flash and recycles old flash as needed, and abstracts it from the system's perspective. (Your computer doesn't know precisely which pages on the flash contain what data.)

So even if you could defrag it, you'd just be undoing all the work the controller does wrt wear leveling and performance optimization.

So when the user need a some data,how to retrieve data for OS from ssd?

 

[PliotronX]

There is not a mechanical head taking milliseconds to find the data, it is found in much less time so the only thing defragmenting does is decrease the SSDs life as others said.

 

[dave_the_nerd]

So when the user need a some data,how to retrieve data for OS from ssd?

Simple.

Your computer gives everything a block number. On an HDD, those correspond to physical locations on a platter. (Which is why mechanical optimizations like defragging are helpful.)

The SSD shows the block numbers to the computer, and then maps each block number to a particular page of flash memory. Which piece? Doesn't matter. Change that data (write to the same block) and it'll probably wind up on a different page. It's all transparent to the PC.

Well, okay, not completely transparent - there are utilities which can dig in there and read page mapping info. But as far as your OS is concerned, a SATA SSD is a very, very fast HDD and that's all there is to it.

 

[BonzaiDuck]

Go into the Properties page of the SSD volume. Make sure "scheduled Defragmentation" is turned off.

 

[BD2003]

Even though access times are orders of magnitude better than HDDs, random R/W speeds are nowhere near as high as sequential, even on the fastest SSDs. Those SSD torture tests are proving that the drive life is rated very conservatively, and 3D NAND is supposedly going to significantly increase their endurance several times over....

So even though it's not an absolute necessity, I do wish SSD manufacturers would develop some method for us to defrag if we choose.

 

[MagnusTheBrewer]

Even though access times are orders of magnitude better than HDDs, random R/W speeds are nowhere near as high as sequential, even on the fastest SSDs. Those SSD torture tests are proving that the drive life is rated very conservatively, and 3D NAND is supposedly going to significantly increase their endurance several times over....

So even though it's not an absolute necessity, I do wish SSD manufacturers would develop some method for us to defrag if we choose.

Please read about how ssd's store data. Having your data occupy contiguous blocks does NOTHING for access or write times. Think of how much time you'll save to organize your sock drawer.

 

[_Rick_]

Please read about how ssd's store data. Having your data occupy contiguous blocks does NOTHING for access or write times. Think of how much time you'll save to organize your sock drawer.

I don't agree completely.
The difference defragmentation makes, is that the system believes that a certain file is contiguous, and will thus generate a a series of access commands that are sequential. If the OS just sends what appears to be random blocks, then the SSD will usually read data a bit slower. The SSD only knows blocks, and not files, so it cannot differentiate between the two different types of accesses.
Now, I assume the difference is mostly because drives will internally predictively read ahead, and then quickly deliver the content without reading flash for every ATA command.

But, to reach the point where an SSD is that fragmented, that you would actually humanly notice the difference, is going to be extremely long. So unless you have a known stressing/fragmenting workload which features regular sequential reads, (which you cannot back-up and subsequently recover, while you reset the drive) you do not need to defragment.

As for a tool which defragments: An SSD defragmentation would simply need to update the LUT, not the actual content of the flash. Alternatively, a solution would be to do away with hardware controllers and break the layers, have the FS deal with flash natively. Then you'll have a direct link of file to flash cell, and you do not need to fragment anymore, since the LUT knows which cells it has to look-ahead for, when a large file is queried. This would move the physical linearity that is limiting in hard drives to logical linearity, where sequentiality is replaced by a notion of contiguousness - one file, one set of flash addresses.
Won't happen though, because you don't usually want to break the layers.

 

[MagnusTheBrewer]

I don't agree completely.
The difference defragmentation makes, is that the system believes that a certain file is contiguous, and will thus generate a a series of access commands that are sequential. If the OS just sends what appears to be random blocks, then the SSD will usually read data a bit slower. The SSD only knows blocks, and not files, so it cannot differentiate between the two different types of accesses.

The time differences are unnoticeable to the user. We're talking about nano seconds. Just as the user can't tell the difference between slow and fast ram without using benchmarking software.

 

[Mantrid-Drone]

There are 'professional' defragmenters like Auslogics Disk Defrag Professional that offer specifically optimised for SSD defrag profiles. Presumably these minimise the number of write cycles.

However just because an option is provided does not make it a good idea to use it and my own online researches elsewhere have always reflected what most others here have said.

It simply isn't necessary as the benefits, if any, will be unnoticeable in practice and do nothing but reduce the life of the drive. Whether that would prove significant though is still debatable. Whatever the case if there's no clear benefit it is a pointless waste of time doing it.

 

[BD2003]

The time differences are unnoticeable to the user. We're talking about nano seconds. Just as the user can't tell the difference between slow and fast ram without using benchmarking software.

And yet for the same reason that people buy fast ram, I'd like to keep my SSD operating as close as possible to it's theoretical max performance. I'm not particularly concerned about SSD life, I think it's a problem that's blown way out of proportion. A defrag every now and then isn't going to destroy it.

Honestly, it's more of a theoretical thing, more of a "why not?" kind of thing, not something to obsess over.

 

[dave_the_nerd]

Dude, there's nothing to defrag. It's snake oil.

 

[Elixer]

And yet for the same reason that people buy fast ram, I'd like to keep my SSD operating as close as possible to it's theoretical max performance. I'm not particularly concerned about SSD life, I think it's a problem that's blown way out of proportion. A defrag every now and then isn't going to destroy it.

Honestly, it's more of a theoretical thing, more of a "why not?" kind of thing, not something to obsess over.

But the "why not" is because, it is useless.
As was pointed out, the way the data is stored on a HD vs a SSD is completely different, it isn't even close to how each device handles data.
Most "SSD defrag" software just does a bunch of TRIM commands, and that is it. It don't (can't) actually move the data, since that is the job of the controller.

 

[mikeymikec]

Let's try explaining this another way.

A hard disk's method of retrieving files is physical / manual. A head has to be physically moved to the correct location on the platter (as well as the platter being in the right position for the head to read the data), kind of like a librarian sitting in a library. Ask the librarian to find a book and they'll walk to the correct location, pick the book up, come back to the front desk and give it to you.

Now let's say there's a big file, or in the librarian example, you're asking for the entire series of a particular encyclopedia. On a recently defragmented disk, or in a well-organised library, the contents of that encyclopedia (or large file) will be located in the same place (continuous block), so the librarian can just go to one location in the library with a trolley and pick up all the volumes of that encyclopedia in one go (and so the head does one data seek, finds it and reads it), rather than having to walk around the library because the library is untidy (or disk is fragmented, so the head is having to make lots of journeys). As for the disk, its read speed goes way up for a large file because it doesn't have to spend time seeking for bits all over the platter.

Defragmentation (or tidying the library) is good so that time isn't wasted seeking all the bits of a large file.

SSDs do not have a drive head. There is no movement inside the SSD. If a file has been splurged in a thousand fragments across the SSD, the retrieval time is the same as if the file was saved in a single fragment; the SSD still has to request the portions of the file in just the same way.

Defragmenting an SSD is just as pointless as hypothetically defragmenting RAM or the cache levels in the processor, except with an SSD there is a limited amount of writes it can do in its lifetime, and you're wasting those writes in an utterly useless exercise.

 

[Fred B]

For me defrag is a part of maintenance of the pc , first thing is to make defrag rapport to see what files are fragmented and how much the fragmentation is . With the rapport i try to remove files from ssd that are bad fragmented . For example intel log files C/Intel/logs are often very fragmented due the nature of log files , so there could be a text document with 50MB in size . That text doc is being rewritten very often without delete it grows in size and amount of fragments . So when intel log writes 1Kb to log it rewrite 50 mb file that cause write am plication that is bad for ssd . But when starting the pc without the log file there wil be a new one created with no write amplication and fragmentation , but this files grow fast and fragments a lot so disabling al the intel services is possible to stop writing .

When file is fragmented it can not be read sequential but random , the ssd does not give a shit but ntfs does . With ntfs sequential is made of 64k blocks , for example there are 1000 files of 64 K to make 1 file that can be read sequential . When it is fragmented it looks like 64k/64k/32k/16k/8k/4k/8k/64k/64k , what happens is the ssd can not get sequential full speed and need more iops to complete the read . It is the little law with 64K files http://en.wikipedia.org/wiki/Little's_law

^_^

 

[mikeymikec]

@ Fred_B

Your first paragraph, reading from 'For example intel log files', makes sense, but the only logical conclusion to draw from it is to reduce unnecessary writes by configuring the software differently (or removing it).

Your second paragraph doesn't make any sense. I'm not trying to be nasty here, I'm guessing that English is not your native language, but I think it's a combination of you being technically incorrect (regarding file systems) as well as the way you've communicated what you're trying to say. There's an abstraction layer that I don't think you're aware of that perhaps you ought to read up about:

http://www.thessdreview.com/daily-n...ion-and-trim-in-ssds-explained-an-ssd-primer/

I think you ought to read the whole article, though with particular focus on the sections starting from 'OS awareness versus drive awareness'.

 

[imagoon]

There is a specific point where defragging a file on an SSD (not the entire SSD) will have an effect. There is a noticeable performance drop when the file appears to be fragmented to NTFS. There is additional over head as the fragment count goes up. However I would like to clarify that we only see this on systems running say SQL with a a couple TB of SSD and having the MDF/LDF get in to the many millions of fragments. The look ups start to slow because NTFS needs to plow through a table of cluster locations to find the blocks the database needs. Running a "coarse" defrag on the file helped that issue a lot. We didnt have the goal to get the entire database to 1 contiguous file since that would never happen but to a fragment count somewhere around filesize / 64MB.

The above is never going to happen to a home user using a SATA SSD right now by the way.

 

[_Rick_]

mikeymikec, sequential reads are up to 5 times faster than random reads.
I suggest you read my post further up, to understand what the difference is between a fragmented file system, and a defragmented file system.

At this point, the drive geometry matters much less, than for HDDs, but the FS virtual geometry still matters, as long as we linearly address the SSD (never mind how it translates those addresses - this is almost irrelevant, except when writing a FS defragmenter specifically for SSDs, where this internal address translation can be exlpoited to defrag with O(n) (n = number of files) writes to flash outside the addressing table.)

I think that's the point Fred B was trying to make. SSD fragmentation indeed doesn't matter. FS fragmentation (the mapping of files to block ids) still matters, in some applications, as evidenced by benchmarks showing slower reads.

If you use a single FS for your SSD, and store the logs for multiple processes running on a server/cluster on it, and then want to read those logs at high throughput, to do some automatic performance/quality analysis, then you want to make sure that these log files do not fragment. Arguably, you do not want to defragment them either, since the performance impact would kill the application, but you have to take steps in advance to prevent fragmentation, either by using separate file systems or by creating empty files to make sure your log files are placed at a sufficient offset.
How it looks like on the SSD matters very little, but read-ahead increases performance massively, and there are fragmentation-sensitive workloads, so the problem should still be treated seriously.

This is EXACTLY liek the discussion of RAM speed and latency. IF your workload works well with cache, and doesn't do much streaming, memory speed and latency aren't relevant. If you have streaming applications (think GPU-like operations using SSE or AVX) on large datasets, then you need that bandwidth. Memory latency is mostly useful if you have a large dataset, and you cannot just stream the data through, but need to access specific points as a result of a calculation. That's an even rarer use case (large scale AI would come to mind), but still, there ARE use cases, for high speed, low latency main memory.

And there ARE use cases for managing fragmentation of filesystems that mostly reside on SSDs.

 

[BD2003]

To me it seems rather simple, although maybe someone can explain where I'm misunderstanding.

You can look at *any* SSD benchmark, it's it's clear that sequential reads are much faster than random. Obviously there's a major difference between a random read and a fragmented file, but regardless, there's a difference there.

I fully understand that its orders of magnitude less of a problem on a SSD, but theoretically, fragmentation leads to lower performance, no?