SSD with Defragmented Win7

I have been thinking how I can possibly achieve defragmented win7 on SSD.

What if I install Win7 on a HDD first and run defrag then take the image.
Install win7 on my SSD using the image just created on HDD.

I am not certain how the imaging works as I didn't have to do it in the past.
If image backup writes back as it was defragmented way back to SSD.
Then we should have slight performance boost.

Is this logical and do you think we can boost the performance a bit?

I am not able to perform it right now since I am waiting for HDD Sata connector.
Then I will definitely have a go on this.

Regards,
Yalcin

 

SSDs have no seek time and no read latency, as they're solid state. Theres no point defragmenting it at all. Rest your mind

 

No seek time? are you sure?
Wouldn't it improve the read time if the files not fragmented.
I believe gathering file clusters from sequential blocks would be easier
than having to look for many blocks as SSD's have to do searching for file clusters and that requires time as well.

 

I'm going to have to respectfully disagree. The change in read/write time to an individual cluster may be unnoticeable, but the memory controller can slow down a bit when reading and writing large files if the drive gets very badly fragmented. Not a huge amount, but noticeable enough in HD tests. The problem isn't the read head ticking around anymore, but an overwhelmed controller. That said, it takes a really large file and poor SSD file management by the OS to get to the point where it's really noticed.

 

We are looking at this all wrong folks. The basis of fragmentation was the picking up and storing of files on a disk which was spinning at up to 7200 rpm while an arm has to menauver itself and find just the right spot to do it. Access time on a hard drive were horrid in that for a large file, which makes a few passes to get everything there, you are technically multiplying the access time.

Its the mechanics of it all. On a SSD there is no mechanics and it is all done through a pipeline (if I may express it that way). This is why, unlike a hard drive, the average access time for a ssd is about .1ms. How we are going to improve on that is beyond me.

For a couple of years now, I haver nbeen trying to show others that things such as Prefetch, Pagefile (if u have ample RAM)Superfetch, indexing and search are really things that were created to speed up the slow process created by the bottlenecking of the hard drive and now it is starting to be generally recognized that this is correct and is even being put in print now by Intel and Microsoft as well as countless other sites.

Even hibernate is useless on a SSD as the system starts as quick from shut down as it does on hibernate.


Now to complicate this, all SSDs have wear levelling algoritms which decide where the information goes dependent on how much each block of ram has been used. Even info previously stored is never static on a drive and the SSD is able to keep track of all this. Wear levelling, in effect, recognizes and takes care of fragmentation, as little as it is, as does TRIM or manual disk optimization if you haven't got TRIM.

Hope this helps...

 

Les, I am totally new to this SSD tech with no solid knowledge.
Are you saying that there is no fragmentation on SSD's? That is all the files written in sequential blocks with no fragmentation at all??
That is too good to be true since file sizes to be written do differ and what's written is not in size order. I believe it is rather written in first come first serve order. Then we are talking about fragmentation which I believe it would create higher read access times.
I know I might be talking totally nonsense but I will definitely look into this.

 

Almost. Some programs take a fair amount of CPU intensive initialization time that is avoided with hibernation.

That said, I have a 128GB SSD (120GB formatted capacity) with 6GB of RAM. I'm not gonna waste 6GB of disk space on hiberfil.sys when the differences are negligible with my use. Other people who run apps with nasty startup sequences might find the tradeoff worthwhile.

THAT said, 95% of consumers will be better served by disabling hibernation. One of those "If you don't know, you don't need it" situations.

He's not saying that they don't fragment. He's saying that fragmentation doesn't matter for the most part with SSDs because they have a constant seek time, instead of a variable one like a spinning drive, and they effectively self-defragment invisibly to the OS and the end user. Especially with TRIM enabled/supported, the SSD makes the most intelligent decision on where to put things on the drive for fastest access.

 

I have just analysed the SSD with Ultimate Defrag and if it is working in correct way SSD is fragmented by ~10%.

 

K...lets stop right here eheheheh. DO NOT worry about fragmentation. The whole thing is taken care of. If u r using ONLY a SSD, shut any or all defragmenters down because you are needlessly reducing the lifespan of the drive.

Fragmentation does not affect your seek times in a SSD whatsoever and Pita...nice return.

 

Why did I open this topic anyway? trying to get acknowledge from someone else?
If I need to do it do it yourself and see if it helps. At the end no-one seems to be expert in this tech as it is new to everyone else.

 

Wear-leveling has more to do with write cycles to blocks than with file coherency in the MFT, which is what most defrag on HDDs is meant to address. Defragmentation on SSDs is actually bad for wear-leveling, which is part of the reason it's discouraged for SSDs. Some amount of fragmentation actually improves performance since data will run through multiple channels instead of all being read off a single page. In HDDs, data runs through a single read head (ignoring RAID), while SSDs can pull data from multiple locations at once.

I misspoke earlier when I mentioned slow reads. I should probably also note before I go on that in my head, TRIM on SSDs and defrag on HDDs perform essentially the same function - remove the junk and make writes faster. I interchange the terms for SSDs in a very bad way.

An SSD fragmented over the long-term where you're trying to write a large file to blocks that haven't been properly maintained (erased) and where you don't have enough scratch space will have spikes of slow-writing performance because of the junk data lying everywhere that needs to be erased first. TRIM-enabled SSDs clear out junk data and mostly "deleted" blocks, thereby increasing the amount of free blocks and scratch space for writes, so performance improves. As Les noted, if you don't have TRIM, do what you can with manual optimization.

I think Anandtech had an article on TRIM and SSDs last year that was a solid explanation of how TRIM helps. Ultimately though, I think the conclusion I've reached from multiple tech sites has been that the best way to improve SSD performance is to clone the whole thing (not at byte/block level), wipe it, and rewrite EVERYTHING all the data so it's distributed in the best way for SSDs. Note, this doesn't mean sequentially as in HDDs, but dispersed over the drive so that data will read from multiple pages at once.

Not an expert, but I hope that helps.

 

woofer00, I suggest you read my opening post again. I was not planning to do defragmentation on SSD. Rather I wanted to take the image on a HDD secure erase the SSD and put the whole thing back.

Anyway enough of this. no need talk further with you experts (copying and pasting someone elses opinion) with pocket full of money as I don't have much money to waste couple of expensive stuff till I become an expert.

 

I think I may have sounded a bit blunt there but was only trying to give you the best advise. Defagging is not good for the SSD which is why its disabled automatically.

Apologies if I sounded miserable...just trying to help.

 

You were asking about imaging the drive to improve SSD performance, and the thread went on to talk about why doing that is a waste of time if you have TRIM - this is still true. What you want to do isn't going to help as much as making sure TRIM is working properly since the largest write performance factor is not the file distribution/coherency, but free space and erased blocks. Read performance will not be affected (that you will notice, anyway), if the controller is doing its job.

That said, here is what you want (I think. I'm trying here, so maybe you need to get off your high horse. This is a free forum. If you want a better answer go hop on a Acronis/Norton forum):
There are a couple different ways to clone. You can do a perfect image that will just restore byte for byte, empty space and all - you don't want this. A perfect restore will just put everything back exactly where it was.
You can also do a partition/smart sector clone via Ghost (haven't used it in ages, but I imagine the function is still in there) that will go file by file and effectively defrag since it's copying a single files at a time. If you write that ghost back to the ssd, it will send back file in sequential order. I don't think Ghost picks up the MBR, but that should be recreated as you write it. However, be prepared to fix the mbr and mft. I'd create a perfect image of the drive just to be safe.

All that having been said, I re-emphasize - this is a giant waste of time is TRIM is enabled as Les and Pitabread also stated. Fragmentation is a non-issue on SSDs and actually improves throughput. TRIM will clear junk blocks and improve write performance. You might see a tiny performance hike by cloning, wiping, and reimaging, but it's not worth the time or effort.

 

You can also use Drive Snapshot for imaging and restoring a partition. There is a 30 day full function trial version. You can image the SSD partition, restore it to a HDD partition of the same size(this can be on an external disk, USB or eSATA). Then defragment this HDD partition with Auslogics defragmenter, take again an image from the defragmented HDD partition and restore it via Drive Snapshot to the SSD partition. It don't know, if the performance of the SSD partition increases by doing this. Maybe I'll try, if I get familiar using HDDERASE with my 3 days old SSD.
Ok, I forgot to mention, that for imaging and restoring of the SSD partition, you have to use a boot cd(WINRESCUEPE or CTRESCUEPE by c't with Drive Snapshot implemented).

 

Thanks Maximinimaus, appreciated. I have all the tools you mentioned. I am just waiting on a SATA connection cable to connect my HDD to do all this.
I was jut unsure about restoring an image puts back as it is set up or randomly. I don't think it would be any worse and hoping a bit snappier SSD.
That's all.

 

I just did it and restored the defragmented image. Good news is, there is no perfomance degradation.
But there is also no visible perfomance improvement.
Crystal Diskmark shows similar results as before restoring, but this is a synthetic benchmark.
I ran WINBUILDER with the projects cc7pe, ccmultiboot and Win7RescuePE after restoring
and again after online defragmenting my SSD partitions with Auslogics defragmenter.
The logs show approximately the same elapsed time to build the projects before and after defragmenting.
My conclusion is, defragmenting my SSD is not necessary. Maybe because my SSD supports TRIM. It was a nice experience.

 

Thanks for doing this Maximinimaus. Is there a way to measure read access time? Any difference?

 

Access times are constant on SSD's, like I said. The read rates may be different, but he said that he tested that and didn't see any difference in real-world performance. Given he can't go back before he did it and run Crystal or something like that, I'd say his results are still pretty conclusive.

Solid-state = no moving parts = constant access time. Just like your RAM latency.

You might want to try reading again the posts of the experts you derided earlier.

 

When two talking why do you have to get involved and do the explanation instead of him you googlers. In what part of my question was begging for your explanation you copy and paste expert.

FYI, read access times are not constant in case some ask you can copy and paste my statement.

 

We don't take to personal insults around here. That is a warning. See the green name? That means you should take what I say seriously.

You are the one asking questions about SSD's without knowing anything. If you looked, you would see that I own one, and have ran many tests on it, as well as having read many technical articles on them.

Whether you think I'm a copy and paste expert or not, I actually know a heck of a lot more than you concerning this topic and I'm trying to educate you so you don't ask such irrelevant questions. Asking if the access time of an SSD has changed is like asking if the number of pixels of an LCD has changed if it shows different colors. It shows a profound ignorance of the realities of the hardware. SSD's have a constant read access time due to their architecture. They can have variable read and write speeds for different sized data blocks when drives are filled or fragmented due to no TRIM support, but they will always take the exact same amount of time to access any single given bit of data on the drive, which is what "access time" is defined as.

 

I have run Crystal Diskmark after a clean Windows 7 install(aligned, performance tweaks a.s.o, ) on the brandnew

SAMSUNG SSD PB22-JS3 FDE 2.5" 128GB
Size 128.0 GB
Firmware Version VBM9LD1Q

The results were similar. I used already the Intel RST driver.
I have no results regarding the perfomance of the MSAHCI driver.

As I have 2 images(defragmented and fragmented) of the same OS partition, I can easily restore the fragmented version.
But in my opinion that makes little sense because of the behaviour of the SDD's.

Crystal Info shows 91% good. As this SSD was brandnew should it not be 100%?

 

having a file spread to thousands of fragments still means it has thousands of times the access. file defragmentation can, thus, help. even if it's just little (defraggler can quickly do file defragmentation)

hibernate allows you to continue your work where you left it. this completely different to closing all apps, shutting down, starting, opening all apps, loading all files again. might be "performance-useless", but not "usability-useless".

oh, and.. hi

 

ehehehe... Point Conceded

 

still, of course, your point is overall still right: forget about defragmentation on an ssd. it's very useless. use your system the way you like, it automatically adapts to you anyways.

 

You assume the access time is serial. IIRC the X25-M has 10 parallel channels that severely cut down on access time, scaling better than a factor of 10 for large numbers of file access operations. Regardless, there's still no physical read head bobbing and weaving across the drive. Maybe there'll be slowdown from having to access a ridiculously large file table, but that's only really going to show an effect on the microsecond scale, which for all intents and purposes you cannot perceive.

 

This is from wikipedia
# Defragmenting the SSD is unnecessary. Since SSDs are random access by nature and can perform parallel reads on multiple sections of the drive (as opposed to a HDD, which requires seek time for each fragment, assuming a single head assembly), a certain degree of fragmentation is actually better for reads, and wear leveling intrinsically induces fragmentation. In fact, defragmenting a SSD is harmful since it adds wear to the SSD for no benefit.

Solid-state drive - Wikipedia, the free encyclopedia