Another 8GB worth it for a RAM disk?

ReadyBoost's secondary purpose (after acting as a second-level random I/O cache) is to act as a storage medium for Readyboot (yes, Ready*boot*). Readyboot is basically the old-school pre-fetcher for boot-time files optimisation. It provides Windows with a potentially better source to read boot-time files from, at least those that are read using a random file I/O handle.

ReadyBoost does not serve in anyway as a Superfetch storage medium. Superfetch is purely designed to dredge up frequently used files (ANY files that meet specific sizing criteria, and not just specific types) and store them in RAM.

ReadyBoost operates at the file-level, but only for files that are being accessed in a random I/O manner. It does not operate at the "HDD cluster" level. The only part of Windows that is remotely aware of HDD clusters is the ntfs.sys.


And the source most of this information? Mark Russinovich's Windows Internal 5h Edition book.
 
Last edited:
NathanE said:
ReadyBoost's secondary purpose (after acting as a second-level random I/O cache) is to act as a storage medium for Readyboot (yes, Ready*boot*). Readyboot is basically the old-school pre-fetcher for boot-time files optimisation. It provides Windows with a potentially better source to read boot-time files from, at least those that are read using a random file I/O handle.

ReadyBoost does not serve in anyway as a Superfetch storage medium. Superfetch is purely designed to dredge up frequently used files (ANY files that meet specific sizing criteria, and not just specific types) and store them in RAM.

ReadyBoost operates at the file-level, but only for files that are being accessed in a random I/O manner. It does not operate at the "HDD cluster" level. The only part of Windows that is remotely aware of HDD clusters is the ntfs.sys.


And the source most of this information? Mark Russinovich's Windows Internal 5h Edition book.
Click to expand...

I read somewhere it cached on a sector level, maybe I was getting confused with cluster level. I am aware however it caches only part files, for example if you have an Outlook file, it may choose to cache only the parts regularly accessed.

This aside my experience of putting readyboost on SSD is that it makes a big difference to disk access, and computer feels very snappy and SSD like (yes I have once used SSD as boot drive). I do however also use SSD's for temp files, page files, and indexing.
 
NathanE said:
The thought of using a RAM disk as a "page file" location is rather amusing.

In short: Don't do it. Ever.
Click to expand...

Why not? I can't think of a reason why it would be bad.



As for readyboost, it won't let me try it because the system disk's performance is high.

Instead of using readyboost, why not just move the files you want speeding up? Obviously this isn't a solution suitable for everyone (or even possible with some files). Compiling from ramdisk is rather nice :)
 
weird_dave said:
Why not? I can't think of a reason why it would be bad.
Click to expand...

The primary goal of the page file is to increase your commit limit. If you set aside ram for a ramdisk then you lower the commit limit. So you don't really gain anything. Plus it takes more overhead to access memory through a page file on a ramdisk than accessing it directly.
 
I'd rather not have one at all, but some stuff requires it :(
I've got the ramdisk anyway, so putting the pagefile there is only using up 16MB most of the time. I'm not using the ramdisk purely for the pagefile, it's doing plenty of other stuff too.
 
JasonM said:
This aside my experience of putting readyboost on SSD is that it makes a big difference to disk access, and computer feels very snappy and SSD like (yes I have once used SSD as boot drive). I do however also use SSD's for temp files, page files, and indexing.
Click to expand...

Interesting thread and ignoring the naysayers I think I see the performance boost - albeit it is risky to perform in RAM disk.

Do you happen to have a blog or this documented anywhere ? Especially interested in how you set up the temp files and indexing
 
Subliminal Aura said:
Interesting thread and ignoring the naysayers I think I see the performance boost - albeit it is risky to perform in RAM disk.

Do you happen to have a blog or this documented anywhere ? Especially interested in how you set up the temp files and indexing
Click to expand...

No blog, but just the original readyboost thread I posted with some findings. When that was written I only had 1 SSD, and was not storing temp files on SSD. I have 2 SSD's now.

To move temp files, just make the temp folders on SSD, then in environmental variables move the folders over.

To move HDD index's, make an 'Index' folder in root of SSD. Then run indexing (from run command), and in advanced settings change index location to new location on SSD.
 
Last edited:
JasonM said:
No blog, but just the original readyboost thread I posted with some findings. When that was written I only had 1 SSD, and was not storing temp files on SSD. I have 2 SSD's now.

To move temp files, just make the temp folders on SSD, then in environmental variables move the folders over.

To move HDD index's, make an 'Index' folder in root of SSD. Then run indexing (from run command), and in advanced settings change index location to new location on SSD.
Click to expand...

Woah very nice ... Thanks for that.

EDIT : Ignore - From Wikipedia

" Windows 7 allows up to eight devices for a maximum of 256 GB of additional memory. " - So just partition your SSD at your hearts content
 
Last edited:
Subliminal, what the topology of your HDD's and SSD's?

Subliminal Aura said:
BTW How do you regularly prune the %TEMP% folder ? Or should I write a script to purge it on logoff ?
Click to expand...

Most programs will clean up the temp folder as they go along. I have just checked and I'm seeing 81MB in AppData\Local\Temp and under 100k in temp folder.

If your worried, then after a reboot just try deleting items out. Anything that's in use should be locked down and won't delete anyway.
 
Last edited:
Subliminal Aura said:
OK ta...

BTW Have you tried eboostr ?

It's the second time I've bumping into it in as many days :/

http://superuser.com/questions/333172/how-can-i-make-windows-7-readyboost-persistent
Click to expand...

I never heard of this before.

Regarding readyboost cache being lost on reboot. I tend to hibernate the machine. Not so much for readyboost, but being a developer I often have many visual studio's / sql displays on screen. Hybernating is most productive for working again next day.

If you do reboot, it's not a big issue as readyboost will quickly populate what's currently being used. From experience I would say it's around 15 minutes after reboot before the c:\HDD really settles down (windows prefetch is working also here). The downside is boot times, but if your someone who leaves the computer on for many hours, the extra start up time is inconsequential compared to the hours spent during the computers working day.

One things to add. Because temp files & disk indexing is moved away from C: drive, then the queueing load on the C: drive is less. So even you have only moved part files away from HDD to SSD. The workload on HDD is less, speeding up the remaining HDD access.. hope that makes sense..
 
Last edited:
drakioned said:
HangTime,

How did you use RAM as your %tmp% directory? What software did you use and did you have to do any tweaking?
Click to expand...

I just set it in environment variables, you don't need any software.

As for the whole pagefile on RAMdisk thing, I have yet to see a good explanation of why we shouldn't do it (assuming of course we have sufficient memory to avoid unnecessary paging)..
 
Sorry to the OP as this thread got of topic some time ago, however for those interested this is the current drive topology of my system.

readyboostPart2.gif
 
That rox, I'll be doing exactly the same albeit I'll have some key apps on the SSD too like say eclipse, VMs etc. Probably won't run a pair of SSDs as that looks overkill plus it's going to be a pain if one of them dies. :D
 
Subliminal Aura said:
WAIT ! Spanned readyboost/page file ? It's not really is it ?... Doesn't windows treat them as separate files ie it's not like placing a pagefile on a RAID0 array
Click to expand...

Windows does treat readyboost / page file as separate files on each drive, however if it sees more then one respectfuly, then it shares data between the files.

So when it reads/writes to page file it, it will be splitting the data by half, and writing data to each SSD.

Same is happening with the readyboost, however I've noticed somtimes each readyboost file is not been used simultaneously. With readyboost it write for some time data to one SSD, then start writing to the other SSD. I have a feeling readyboost is checking for latency, and if say temp files are being written it hold off using the readyboost on that drive, and switches to another. No evidence to back this last point up however, just a hunch I have by watching activity.

Both drives are not in raid, allowing trim to work as normal.
 
You must log in or register to reply here.
Back
Top Bottom