Why disable Windows indexing on SSDs?

Typically, the reason stated for disabling Windows indexing on an SSD is that "the seek times on SSD drives are so fast that you don't need indexing". That makes no sense to me and I'm beginning to wonder if I'm the only one. Here's why:

• Finding a keyword in a file on an unindexed drive is not a matter of merely quickly seeking to a number of files. You also need to read the contents of each file to see if there is a match. Seek times of SSDs are a couple of orders of magnitude lower than hard drives, but their read speeds are better only by a factor of 2 or 3 (and sometimes not even that much). And you'll be doing much much more reading than you'll do seeking when you're looking for a keyword in file contents on an unindexed drive.

• More importantly, indexing is not a mechanism that quickens seek time to access a given file, it's a mechanism for quickening the discovery of which file to access. As the number of files you have to search through grows, even the lowliest indexed hard drive, will quickly beat out the fastest unindexed SSD RAID array on the planet.

Here's a simple example: Let's say you have a drive volume that has 50,000 files on it and you're looking for the first file with the keyword "rosebud" in this entire volume.

Here's how long it would take on an indexed hard drive:

- Time to seek to the index file: 15 ms
- Time to find the index entry for "rosebud" in it: (conservatively) 500 ms
- Time to read the file pathname listed on this index entry: (negligible, but let's say) 50 ms
- Time to seek to the discovered file: 15 ms

Total time: less than 1 second

Here's how long it would take on an unindexed SSD, assuming the correct file is happened upon after scanning "only" 20,000 of the files on the volume:

- Time to seek to 20,000 files: 0.1 x 20,000 = 2,000 ms
- Time to read contents of 20,000 files and look for a match: (optimistically) 1 x 20,000 = 20,000 ms

Total time: 22 seconds

Am I smoking something, or is everyone else?

You don't have to seek to files; when you're searching you're reading meta-data about directory structure, file nodes and their properties (size, creation date, modification date, filename, etc).

Large chunks of this metadata could be cached, and you certainly don't need to read the actual files, unless you're searching within files; but that option does not apply to the Indexing Service i assume.

sub.mesa said:

Large chunks of this metadata could be cached, and you certainly don't need to read the actual files, unless you're searching within files; but that option does not apply to the Indexing Service i assume.

Click to expand...

If the only thing in question were searching for file names and metadata, I might agree. But, the main purpose for indexing drives (as well as the main reason index files are frequently referred to as being "huge") is the indexing of the file content. The Windows indexing service does index file content. The following sentence is from the second paragraph of this article on MSDN:

Windows Search supports the indexing of properties and contents from files of different file formats, such as .doc or .jpeg formats, and data stores, such as the file system or Windows Explorer mailboxes.

Click to expand...

Disabling indexing is a holdover from the original JMicron ssd which would start stuttering under any type of load. If you look closely at those "ssd tweaking" guides, it can be summed up as doing as little with the drive as posible.

guney said:

Typically, the reason stated for disabling Windows indexing on an SSD is that "the seek times on SSD drives are so fast that you don't need indexing". That makes no sense to me and I'm beginning to wonder if I'm the only one. Here's why:

• Finding a keyword in a file on an unindexed drive is not a matter of merely quickly seeking to a number of files. You also need to read the contents of each file to see if there is a match. Seek times of SSDs are a couple of orders of magnitude lower than hard drives, but their read speeds are better only by a factor of 2 or 3 (and sometimes not even that much). And you'll be doing much much more reading than you'll do seeking when you're looking for a keyword in file contents on an unindexed drive.

• More importantly, indexing is not a mechanism that quickens seek time to access a given file, it's a mechanism for quickening the discovery of which file to access. As the number of files you have to search through grows, even the lowliest indexed hard drive, will quickly beat out the fastest unindexed SSD RAID array on the planet.

Here's a simple example: Let's say you have a drive volume that has 50,000 files on it and you're looking for the first file with the keyword "rosebud" in this entire volume.

Here's how long it would take on an indexed hard drive:

- Time to seek to the index file: 15 ms
- Time to find the index entry for "rosebud" in it: (conservatively) 500 ms
- Time to read the file pathname listed on this index entry: (negligible, but let's say) 50 ms
- Time to seek to the discovered file: 15 ms

Total time: less than 1 second

Here's how long it would take on an unindexed SSD, assuming the correct file is happened upon after scanning "only" 20,000 of the files on the volume:

- Time to seek to 20,000 files: 0.1 x 20,000 = 2,000 ms
- Time to read contents of 20,000 files and look for a match: (optimistically) 1 x 20,000 = 20,000 ms

Total time: 22 seconds

Am I smoking something, or is everyone else?

Click to expand...

You bring up some good points im curious to see what other comment on this. I tend to agree with your argument and it makes sense on may points.

The only reason I can see that people would want to disable Indexing is to save write cycles on the SSD. You can bypass that by moving the index file to another mechanical drive, and it works just a fast as the Index file on the SSD. That's what I've been doing since I first started to use my SSD.

SicKlown42012 said:

The only reason I can see that people would want to disable Indexing is to save write cycles on the SSD. You can bypass that by moving the index file to another mechanical drive, and it works just a fast as the Index file on the SSD. That's what I've been doing since I first started to use my SSD.

Click to expand...

I really don't think that's necessary. I've kept all system on my SSD, including index, swap, restore points, etc., and after 6 months SMART is still reporting 99 wear level. The controllers have wear leveling algorithms such that writes are spread evenly across the cells. The idea that you must move system files off the SSD in order to save these few write cycles for normal desktop usage is just more unproven speculation.

It's more likely your mechanical hard drive will suffer some kind of malfunction before your SSD wears out.

Thanks for the comments.

On one hand, I'm a bit relieved to see that I'm not alone in my opinion. On the other hand, however, I wish more people would respond with the opposing viewpoint, because I'd simply like to hear the justification behind that recommendation (right or wrong).

This recommendation for disabling Windows indexing on SSDs is pretty much universal across the Internet from the humblest forum posting to some of the most respected technology websites (including an article in Computer Power User along the way). I'm having difficulty imagining where this could be originating from. Could it have been something as simple as an early source making this recommendation mistakenly, without thinking about it for more than a second, and then every other source that I'm now coming across blindly copying from that original source? Or is there more to the matter that I'm missing?

Despite the n00bie status, I think this is probably a good explanation.

Xon said:

Disabling indexing is a holdover from the original JMicron ssd which would start stuttering under any type of load. If you look closely at those "ssd tweaking" guides, it can be summed up as doing as little with the drive as posible.

Click to expand...

It's amazing how many tweaks get carried on long after they've stopped being useful. The SSD controllers have changed a lot (and actually can still vary quite a bit between brands), and it's not something that gets advertised much (to non-enthusiasts). It's very possible that some early adopters found that the crappy controllers were helped out quite a bit by disabling a lot of stuff, and it just became the thing to do because it definitely did help those SSDs.

Unless your write numbers increase dramatically or it induces slowdown, I'd say leave it enabled.

InvisiBill said:

It's amazing how many tweaks get carried on long after they've stopped being useful. The SSD controllers have changed a lot (and actually can still vary quite a bit between brands), and it's not something that gets advertised much (to non-enthusiasts). It's very possible that some early adopters found that the crappy controllers were helped out quite a bit by disabling a lot of stuff, and it just became the thing to do because it definitely did help those SSDs.

Click to expand...

I wouldn't be surprised if that's exactly what happened...

It's amazing how many tweaks get carried on long after they've stopped being useful. The SSD controllers have changed a lot (and actually can still vary quite a bit between brands), and it's not something that gets advertised much (to non-enthusiasts). It's very possible that some early adopters found that the crappy controllers were helped out quite a bit by disabling a lot of stuff, and it just became the thing to do because it definitely did help those SSDs.

Click to expand...

I had one of the first generation GSkill + Micron SSDs and some of those tweaks made a difference but are not needed on the newer drives.

Many till seem to worry about prematurely "wearing out" the drive and limit the reads/writes by putting the data elseware but by doing this they limit the total SSD "experience".

When I bought my 2 Intel 80GB1's I decided that these drives should be used with exactly the same parameters as I use a mechanical HD....page file and indexing included.

I've always turned off system restore, hibernation, and other inconsequential crap on my mechanical disks and I do the same for SSDs.

Many new SSD users are making their transition from mechanical drives much harder than it needs to be.

The write load of the index can be quite low if you set it right. Remember that you should set it to index only documents. If you set it to monitor places where files tend to move or are logging the index will have additional load reflecting that. I set it to monitor mostly my files archives and as little programme folders as possible.

so what is the conclusion, why it is better to disable indexing and why it is better to not disable indexing?
Should we disable it?

sblantipodi said:

so what is the conclusion, why it is better to disable indexing and why it is better to not disable indexing?
Should we disable it?

Click to expand...

Leave it enabled. It won't cause any kind of penalty for the SSD's life, as the write load is pretty small. If you're dead set against running it on the SSD, you can just move the Index database to a HDD. There is no reason to completely disable it.

nsx241 said:

I really don't think that's necessary. I've kept all system on my SSD, including index, swap, restore points, etc., and after 6 months SMART is still reporting 99 wear level. The controllers have wear leveling algorithms such that writes are spread evenly across the cells. The idea that you must move system files off the SSD in order to save these few write cycles for normal desktop usage is just more unproven speculation.

It's more likely your mechanical hard drive will suffer some kind of malfunction before your SSD wears out.

Click to expand...

It's not so much the fact of trying to increase the lifespan of your SSD, it's more about delaying performance degradation.
I haven't kept up to date with the latest SSD technology/controller improvements etc since i bought my Corsair X32's over a year ago, so i don't know if the same rules apply, but i know with my SSD's the more files that are written to it, the slower the drive will get over time. And not just a couple of percent over 6 months, were talking over 50% read and write performance degradation in as little as 2 or 3 months.
I have indexing, prefetch/superfetch, hibernation, system restore, write cache etc all disabled, and all system and internet temp files, and page files moved to a mechanical HDD to save write cycles. I only have 60gb of space on my RAID 0 SSDs, so i keep only the essentials installed on it, such as windows 7 and games that i regularly play. Even still i have to backup my drive, do a secure erase and recover my files every month or so, just to keep performance at an as new level.
Here are some benchys, before and after a secure erase and recover.



Uploaded with ImageShack.us

The AS SSD and bottom ATTO benchmarks are after about 1 month of normal use, and you can see up to 50% loss in write performance and up to around a third of lost read performance. The only things that are regularly written and deleted off my SSD are graphics drivers and games. Imagine how much worse the performance degradation would be if it were constantly writing all the extra indexing, caching files etc.

Nice benchmarks, but could you crop that image some?

BTW, do you notice a big difference in how the system "feels" when the performance degrades?

Does the Corsair X32 have TRIM support? If it doesn't then that would explain the performance degradation. All of the newer SSD's have TRIM support which prevents what you're experiencing. Additionally, some drives have very aggressive garbage collection which will provide a background pseudo-trim effect. GC does require free space though, so one workaround is to leave some space unpartitioned to help facilitate that.

My Intel X25-M 80gb G1 has had over 2TB worth of writes and is still running fast, without any secure erase cycles

Drexl said:

Nice benchmarks, but could you crop that image some?

BTW, do you notice a big difference in how the system "feels" when the performance degrades?

Click to expand...

Ooops, yep that's better
It depends. I did notice a performance drop in the months after first buying them before i knew of the problem, thats what lead me to research it. But because i have 2 ssd's in RAID 0, even with a large performance drop the system is still very quick so it's not really noticeable in boot up/restart times or in the responsiveness or "snapiness" of windows or opening and closing small programs etc. It's more like when your installing or moving a large file like a game and you notice its taking a lot longer than it actually should.
Maybe if i didnt do a wipe restore for months and months i would start to see a very noticable day to day drop in performance. But im pretty anal about it so i do a image backup restore every month or so to keep up optimal performance.

Does the Corsair X32 have TRIM support? If it doesn't then that would explain the performance degradation. All of the newer SSD's have TRIM support which prevents what you're experiencing. Additionally, some drives have very aggressive garbage collection which will provide a background pseudo-trim effect. GC does require free space though, so one workaround is to leave some space unpartitioned to help facilitate that.

My Intel X25-M 80gb G1 has had over 2TB worth of writes and is still running fast, without any secure erase cycles

Click to expand...

Corsair released an updated firmware which enables TRIM, but it wont work in RAID. So secure erasing the array is the only way to restore performance.

Ah, I didn't notice you were running them in RAID. Did you try leaving some space unpartitioned to see if garbage collection will help?

Unfortunately the X series don't have a garbage collection feature

Karndog said:

Unfortunately the X series don't have a garbage collection feature

Click to expand...

That's a less than ideal drive to use for raid....ouch.

Neb said:

Click to expand...

I know right, even the older P series has a Garbage Collection feature, albeit a primitive one (have to have at least 15% free space and kicks in after an hour of being completely idle.)

All in all they're not bad drives for early SSD's. Paid $200 for each 32GB drive, and they're still plenty quick in RAID 0 today. And even though at first it was a PITA, i can now perform a backup secure erase, restore in about 10 mins, allocated and all.
I'll probably upgrade when i can double my RAID 0 performance with 2x 128GB drives at least, for around the same price as my current setup.