SSD raid & secondary SSD page file drive

[cloudNINE]

Anyone have some advice on the below setup?

I'm planning on building a new gamer system built around the EVGA X58 SLI #132-BL-E758-A1.

I'm considering using 2x Crucial CT128M225 2.5" 128GB SATA II MLC Internal Solid state disks in raid 0 for the OS boot and applications. Possibly partitioned into C: and D: drives for OS/application separation.

Additionally, I'd like to put the page file onto a separate Crucial CT64M225 2.5" 64GB SATA II MLC Internal Solid state disk.

Memory will be 12GBs of: CORSAIR DOMINATOR 6GB (3 x 2GB) 240-Pin DDR3 SDRAM DDR3 1600 (PC3 12800) Triple Channel Kit Desktop Memory Model TR3X6G1600C8D

OS: Win 7 64bit

Now, here is where I'm wondering how to squeeze out the best performance from a system like this.

Should I use the on-board raid controller from the MB? Or would a third party raid controller be better?

My logic for using a separate SSD drive for the page file is the heavy use it will endure from games paging to the drive. I'm thinking this will spare the main raid 0 drives from excessive read/writes, thereby extending the optimum operating life of the primary drives.

The page drive could be replaced periodically as its performance degrades (if applicable).

I welcome constructive criticism.

Thank you.

 

[cloudNINE]

Intel has stated than a firmware update to support the TRIM command will be available for their "G2" SSDs when Windows 7 is released. That update, combined with the TRIM support in Windows 7, is supposed to mark deleted files as not having to be erased in the drive, thus avoiding write performance degradation over time.

TRIM (SSD command)

The TRIM command allows an operating system to tell a solid-state drive (or "SSD") which data blocks are no longer in use, such as those left by deleted files. An OS operation such as delete generally only means the data blocks involved are flagged as not in use. TRIM allows the OS to pass this information on down to the SSD controller, which otherwise would not know it could trash those blocks.

The purpose of the instruction is to maintain the speed of the SSD throughout its lifespan, avoiding the slowdown that early models encountered once all of the cells had been written to once.[1]

Although tools were already available to "reset" some drives to a fresh state, they also delete all data on the drive which makes it impractical to use as an optimization.

The root cause of the issue is that SSD drives do not know which blocks are truly in use and which are free. While the file system on the SSD will maintain an in-use list, SSDs don't understand file systems, and cannot access this list. This causes trouble in two places:

* SSDs can write 4KB blocks at a time, but, due to hardware limitations, they must delete larger blocks (e.g., 128KB - 512KB). Since the drive does not know which 4k blocks are still in use if they have been written to previously, each write will require a much larger read-erase-modify-write cycle, assuming that no additional free blocks are available on the SSD (i.e., after all blocks are at least partially filled). The term for this phenomenon is Write Amplification

* Wear leveling allows a drive to rearrange its data so the writes are not confined to one corner of the flash chip. Flash cells tolerate only a limited number of writes before they fail, so some SSDs will move data around to exercise all of the blocks in the drive more evenly. Since the drive does not know which blocks are truly in use by its file system, each block of data written to the drive requires an additional write due to the moved block.

So as this article explains, this is more of an operating system issue rather than the drive itself. The drive can only do what is commanded from the OS.

I've used programs to clean flagged files such as Revo Uninstaller - which has an erase feature to permanently delete deleted files and then defragment the drive. I also set the pagefile to clear upon shut down. Not sure if this would accomplish the same thing? But its something I've been vaguely aware of - deleted files not being truly deleted.

This may be a blessing in disguise to rid the drives of all that unseen and hidden data lurking around?

 

[sub mesa]

The drive can only do what is commanded from the OS.

Not true.
The drive can do what it wants, it just needs to remember how the OS thinks the drive is layed out. In reality, SSDs swap LBAs so what your OS thinks is the beginning of the drive, may be somewhere in the middle or at some random location. This doesn't happen in factory condition, but will happen as small writes are done, which are then written to a different place without the operating system knowing. The SSD then just remembers that the new place is actually supposed to be at the place where the Operating System had put them (the LBA numbers), it keeps a list to reference these, called HBAs.

You don't absolutely need TRIM if you create a smaller partition and keep some 20% capacity unused for the small writes. But with TRIM the disk would know which sectors are free because only the Operating System (well filesystem) knows that. So TRIM it just adding an 'interface' of information exchange between OS and SSD, with the SSD being able to gain from it but can also simply discard the command and do nothing.

 

[cloudNINE]

The drive can only do what is commanded from the OS.

Not true.
The drive can do what it wants, it just needs to remember how the OS thinks the drive is layed out. In reality, SSDs swap LBAs so what your OS thinks is the beginning of the drive, may be somewhere in the middle or at some random location. This doesn't happen in factory condition, but will happen as small writes are done, which are then written to a different place without the operating system knowing. The SSD then just remembers that the new place is actually supposed to be at the place where the Operating System had put them (the LBA numbers), it keeps a list to reference these, called HBAs.

You don't absolutely need TRIM if you create a smaller partition and keep some 20% capacity unused for the small writes. But with TRIM the disk would know which sectors are free because only the Operating System (well filesystem) knows that. So TRIM it just adding an 'interface' of information exchange between OS and SSD, with the SSD being able to gain from it but can also simply discard the command and do nothing.

Ok cool, thanks for the information. SSDs are a whole other beast from their predecessor HHDs.

Can you clarify what you mean by "smaller writes" being written to another partition. I'm a big fan of well planned partitioning but have not heard of this scenario before. Or perhaps I have but have overlooked it due to it being a non-issue with most HHD based systems. Would this be in line with the pagefile or is this something different?

Thanks, I'm learning a lot about SSDs on these forums. Great place to get the heads up such things.

 

[sminlal]

So as this article explains, this is more of an operating system issue rather than the drive itself. The drive can only do what is commanded from the OS.

It takes two to tango. The OS has to issue the TRIM commands, and the drive has to be able to recognize and act on them.

 

[Onrac]

http://www.tomshardware.com/news/ocz-z-drive-ssd-solid-state,8684.html

$1,500 you sick twisted freaks!

That's all.

 

[Guest]

I have been doing the same thing with an older system windows xp with 4gb of ram and and 8gb solidstate drive. I was given the ssd and to be honest its to small to do anything else with so I got to playing. In XP there is not a button to click on to change the location of the pagefile, but you can edit a registry key and get the same results. Running pretty good at the moment.

Only thing I would like to add is why waste the money on a 64gb ssd for the pagefile. you wouldnt want to created a 64gb page file and that would be an awful lot of wasted space.

8 or 16gb would be much less of a waste.