Configuring a mSATA mini SSD + 1 SSD + 1 HDD on a GA-Z77-D3H

Helllo all,

I've given up on my two hopelessly temperamental Asus P5W DH Deluxe boards
and have embraced my first Gigabyte board, the GA-Z77-D3H, which is very
basic but all-modern and notably has an mSATA socket, into which I've put a
32 G mini SSD from Crucial. On the first Sata port I've put a 64 G SSD, the
V4 from Crucial as a boot drive, and on the second a Seagate 1T° HDD for
storage.I've provisionally installed Win7 on the 64 G SSD (with BIOS setting
on AHCI) and everything works but I'm a tinkerer and I want it to work
better still !
Is there any sense in installing either Intel Rapid Start Technology or
Intel Smart Reponse (or both?) ? I realise I may have to re-install the OS
for one or both of these, but that's no problem for the moment.
Among the questions and considerations I have mulled are the fact that the
current boot SSD is a bit small at only 64 G and therefore does not leave
much headroom after installing the 64-bit version of Win7 (half is already
used up), and also that it is in fact only SATA2 although it's on a SATA3
port.
Would it make any sense to use the miniSSD on the board as a cache for the
current boot SSD ? Or would that in effect happen automatically, without one
of these Intel options?
And isn't there an official Microsoft tweak, which generally uses a USB
memory stick to speed things up? Could the miniSSD in the mSATA slot on the
board serve in this way too?
Another question is: is it possible to configue Win7 so that the swap file
is on the HDD? If so, how? I didn't find the answer in the offline Win7
help... I seem to remember configuring Win98 so that the swap file was on a
different partition from the boot C: with good results.

Thanks to all those inclined to give me guidance on the above.
I want to build a fast modern machine for future use even if I'm writing
this on an ancient but utterly reliable old Dell....

Leachim Sredna

 

Crucial M4 CT032M4SSD3 mSATA 32GB SATA III MLC Internal Solid State Drive (SSD)

http://www.newegg.com/Product/Product.aspx?Item=N82E16820148610

Article on SRT.

http://www.anandtech.com/show/4329/intel-z68-chipset-smart-response-technology-ssd-caching-review/2

Using the 32GB MSATA to back the 1TB hard drive, seems a
reasonable plan. To get a good locality of reference,
it helps to back a system partition, since when you're
booting from a system partition, you're visiting small
files in the same kind of pattern on each boot. The caching
software can learn that pattern, and more of the data needed
for a fast boot, ends up in the 32GB drive.

If you use the 32GB MSATA SSD to back the 1TB drive, and
make the entire 1TB drive a data drive, then randomly reading
movies off it, the SSD might not accumulate anything of
lasting value. The SSD can only cache 32GB of data, or about
3% of the drive.

As long as there is a locality of reference, and the
drive keeps reading the same data from session to
session you see a boost.

http://en.wikipedia.org/wiki/Locality_of_reference

On writes, there'd be a difference between write-thru
and write-back performance. If the SSD is used to
hold a write, obviously the write goes very fast.
But eventually, you want the software cache, to store
that information on the HDD as well. It really
depends on what triggers writing to the SSD, as
to whether something useful is happening on writes.
(Job gets done faster, as far as the user can tell.)

So let's draw a picture. If the 32GB MSATA caches for
the lowest part of the 1TB drive, and the OS lives there,
maybe you'll get some benefit from the 32GB drive.

1TB drive
+---------+
| | Rest of disk
| | holds data only
| |
+---------+ SRT, back C:
| C: | +----------+
| 64GB | |32GB MSATA|
+---------+ +----------+

You can use the second SSD for anything you wish.

If you don't want to put C: in the 1TB drive, then
just put the 32GB MSATA SSD back in its box for later.

Or, use the 32GB MSATA as a regular SSD for whatever you want,
with SRT turned off. But with SRT turned on, I see the most
benefit coming from it, if it operates as a cache for C:.

With SRT turned off, you have a three drive system.

And I don't see any other particularly useful patterns
there. For example, doing Dynamic Disk and Spanning the
two SSD drives, is not going to do a very good job
of spreading free space around on the flash on the
two drives (the Microsoft dynamic disk code, isn't going
to know how best to treat the flash based drives).
And consequently, I personally wouldn't run a configuration
like that.

Once you've made the purchase decision, to buy the
particular size of SSD drives that you did, you're
kinda stuck with the consequences. By buying the
32GB MSATA, it's more or less dedicated (works best),
doing the SRT thing, and then, backing a C: partition
makes perfect sense. But now you have to decide,
where to store your backup copies of any data stored
on the 1TB drive. So you might still benefit from
purchasing a second 1TB drive (not involved with
SRT in any way), and make sure to back up this setup
every once in a while. Just in case. Windows 7 has
System Image, to help you make the backup. The
System Image, would only copy the busy sectors.
You would not store the backup, on the same hard
drive itself (on the original 1TB drive).

1TB drive 1TB backup
+---------+ +---------+
| | Rest of disk | |
| | holds data only | |
| | ==> | |
+---------+ SRT, back C: | |
| C: | +----------+ | |
| 64GB | |32GB MSATA| | |
+---------+ +----------+ +---------+

*******

Readyboost is a waste of time, if your system has
enough RAM.

http://www.anandtech.com/show/2163/6

Paul

 

Thanks for all that Paul, I'll study it. As you've been told oft times in
these groups, you are brilliant !

 

My thinking now (FWIW) is now as follows, given the hardware and software to
hand that I indicated above :

Install both Intel Smart Reponse and Intel Rapid Start; which means using
the miniSSD (mSATA) as a cache, and installing the OS on the HDD. The new OS
installation will have to be with RAID enabled in BIOS, says Intel. I
further plan to partition the HDD into two (say system C: and then D: for
storage, in a ratio of one third and two thirds).

The other idea that occurred to me in a brilliant flash was to put the
pagefile.sys and the hibernfil.sys files onto the V4 64 G Crucial SSD, in
order to free and speed things up and put that object to good use. I'm not
presently sure how to do that in Win 7 but I'd like to try.

All thoughts on the above welcome !

TIA

Leachim Sredna

 

You can see here, opinions are mixed on the topic.

http://www.sevenforums.com/performance-maintenance/135153-win7-ssd-should-i-move-page-file.html

And one poster, quoting this article, does nobody any
good, because this article is interest in "performance"
and not the lifetime of the SSD. This doesn't answer the
question in a way that we can use.

http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx

What they really needed to provide in terms of information,
is how many gigabytes of writes per day, are done to the
pagefile.sys. Then, a user would be in a better position
to judge the impact to the lifetime of the SSD.

On a system with a lot of RAM, there isn't a lot of reason
to use the Pagefile. When the system starts, some material
is flushed to the Pagefile and never referenced again
(clever design).

But to give an extreme example, look at the 64 bit version
of CHKDSK. It has a "feature", where it uses the entire
system RAM as a scratchpad. (The version of CHKDSK on WinXP
doesn't do this.) If you run CHKDSK on a volume with a lot
of files, then open Resource Monitor, eventually it'll suck
up all the RAM. You can see the column for paging operations,
start to report paging is happening. CHKDSK puts pressure
on the virtual memory subsystem. Now, that would be a case,
where the SSD will get some wear from paging. For a lot of
your more reasonably written applications, the pagefile might
not get any accesses at all.

When the system shuts down, there is a security option
to overwrite the pagefile with zeros. And again, that
eats some of the SSD endurance. But done once a day,
isn't a big deal.

If it was my system, I'd move the pagefile off
to hard drive. So it doesn't hit the SSD. That
would be my choice. The Sinosky information above,
concentrates on the performance the SSD gives, and
no question, the 4KB random reads that paging might
do, would be quite fast on an SSD. Putting the pagefile
on disk, if the pagefile is actually being used,
is going to slow the system down. So when the system
"recovers" after a CHKDSK run, it's going to take
longer if I move the pagefile purely to a hard drive.

You can use Resource Monitor to watch your system.
And perhaps form your own opinion.

Paul

 

In the last episode of <50bb6f0b$0$1367$>,

Do you actually use the pagefile for anything meaningful? Don't get me
wrong, don't disable it (this causes some unexpected side effects since
all RAM requests must then be backed by physical RAM), but you can
likely cut your pagefile to a very small size, allow it to grow quite
large if needed and forget it exists. If you are hitting the pagefile,
adding RAM is a better approach.

As far as hibernfil.sys, if you're not using the other SSD for anything
then sure, go for it, but it's somewhat wasteful if you don't hibernate
frequently. Given how quickly my SSD based systems can power up, I've
moved away from hibernating and instead standby for short periods of
time and otherwise just power off for my own laptop.

 

Control Panel > System and Security > System > Advanced System
Settings > Advanced tab > Performance Settings > Advanced tab >
Virtual Memory Change

I'm running Windows 7 x64 with 16 GB of system RAM and no paging file.
It works fine.

 

In the last episode of <>,

Note that by doing so, you lose out on some of the virtual memory
benefits. Specifically, if an application allocates but fails to use
utilize memory, it gets backed by physical memory which is completely
wasted whereas if you had a small active pagefile, you'd have all of
your system's RAM available for caching and other purposes.

It's not a deal-breaker, but keeping a pagefile enabled is generally a
good idea even if you never run out on physical RAM.

 

Personally, I'd be more curious what is going to happen when the
x64 version of CHHDSK begins to run. Open Resource Monitor
and watch the fun. It seems to stop, before it runs out
of memory, but on my Windows 7 laptop, it tended to "squeeze"
discretionary memory from other running tasks. You'd want to
run CHKDSK on a big enough NTFS partition, something with
lots of files, so the run doesn't stop before the fun is done.

Paul

 

CHKDSK may easily be one of those applications that reserves a huge
amount of memory before it's needed because of potential failures if RAM
is unavailable on short notice.

But I can't speak to whether that's actually true or not.

 

The application is just stupidly designed, but hey, that's just
my opinion. Unless a machine has dropped to a "single-user"
configuration, where you're absolutely sure about resource
usage and what is safe, you shouldn't be doing that. It's
not like the memory is used in an intelligent fashion.
It's abusive, since the OS has a file system cache, which works
perfectly well, and is transparent to other RAM requests (it
backs off if there is any memory pressure at all). You could
use the properties of the file system cache, get to use
virtually all of the system memory for file caching, and
still offer memory instantly to any other application running
at the time that needs it. That preserves the responsiveness
of the machine, under any circumstances. Why they insist on
privately managing all of that "scratchpad" of memory, is
beyond me. One user reported it used 15GB of 16GB or so,
to give some idea how limitless it is. I couldn't test
that high on my laptop, because I have less memory than that.

I only researched the issue, and found a workaround, because
people had complained about slow speeds. If you manage to
use the x32 version of CHKDSK, it can't gulp down all the
memory on a 16GB machine. That was the easiest fix I could find.

Paul

 

Requesting a bunch of otherwise-unused RAM is perfectly safe and
harmless with a properly configured pagefile since the pagefile will
back the RAM allocation requests and RAM will only be assigned if
needed.