HDD 'index' on SSD???

BS Dave · 7 Dec 2011 at 13:42

I read in a thread recently - but can't find it now - about how you could keep the 'index' of a hdd (don't know the exact term for it, but the information about where data on the hhd is) on an ssd to make you access times for you hdd better.

Does anyone know anything about this? saw the thread??

I've got a 500gb wd caviar black atm, but am thinking about getting a m4 128gb as install drive to replace my old 74gb raptor and wondered if there would be ANOTHER benefit, ie making the 500 hdd quicker as well

I'd be running it on a p55 board with an asus u3s6 board

thanks fellas

Dave

Admetos · 7 Dec 2011 at 14:34

I expect it would have been my post.

Yes it's a benefit to move HDD index locations over to SSD. If you open up performance monitor you will see there is a lot of access on these index database (both read and write). If you sort your C: drive into either max bytes read or write, you see Indexing is normally top / near top of disk activity.

Create a folder called 'Index' on your SSD.

Run 'Indexing' from start command. Then choose Indexing Options. Then Advanced and point indexing over to the 'Index' folder you have just created. It will take some time but Windows Indexing will rebuild the Index database on your SSD.

I run a lot of things on SSD. Not shown on here is my chrome temp folder. My PC is very responsive despite OS/Apps/Data on HDD.

wonko · 7 Dec 2011 at 17:32

IIUC, the windows indexing service catalogues the files on the drive to speed up any searches you do - moving the index databases won't speed up general access to hdds.
The indexing should run in the background when the machine is idle, so being at the top of the i/o list isn't really be a concern if you're not competing for resources at the same time. To reduce the overhead you can limiting the indexing to only those folders/disks that you might want to speed up a search on.

Admetos · 7 Dec 2011 at 18:59

You would expect the above to be correct, however I've noticed indexing files in use at peak times of disk access.

The following is screen shot of disk access when compiling a large project in Visual Studio 2010.

F: is SSD with Indexing + Readyboost
K: is SSD with Temp files + Readyboost
H: is HDD with actual development source files being compiled.

wonko · 7 Dec 2011 at 22:19

Hi Jason, you may well be right about the indexing service running when the machine isn't completely idle, but in your screenshot it's only reading about 70K/s from the F: SSD. Unless there's substantially more writing going on then it shouldn't be slowing the machine down much.

Admetos · 7 Dec 2011 at 23:07

Hi Wonko, the indexing bandwidth like everything else fluctuates a lot, I think it's more access times however, also when the alternative is all access competing over 1 or 2 HDD's.

It's difficult to measure real life performance, however I have measured Visual Studio build times.

I moved my source files from HDD to SSD, on a large project that takes circa 1 min 30 seconds I can't separate the build time by even 1 second, this is comparing to having the source files on HDD. So everything I have done regarding SSD (indexing just one) has added up to make a good improvement. My machine is a development machine that runs all day with many different applications and it's very responsive, there is certainty none of the typical HDD lag you can sometimes get.

BS Dave · 8 Dec 2011 at 07:53

thanks for the reply both. Jason M it was indeed your post i was referring too. Wonko, thanks for your replies as well.

I'm not gonna be much of a power user so i might just put my OS on the SSD.

Thanks

Dave

wonko · 8 Dec 2011 at 10:21

Hi Jason, you're probably right that it's the seek times while accessing the index files that has a bigger impact than the throughput. Sounds like you've spent a lot of time analysing and tweaking to your needs :cool:

.

Hi Dave, good luck with the SSD. Putting the OS on mine made a signficant difference to boot times, less obvious when 'up and running'.