I recently updated my main system to a new Intel Sandybridge based setup which included a Asus P8Z68-V motherboard, as you may have seen. One of the features of the Intel Z68 chipset upon which this motherboard is based is Rapid Storage Technology (RST) which aims to use a Solid State Drive to cache the files your system uses frequently to improve system performance. While many people choose to install their operating system on a SSD and use a cheaper mechanical drive for applications and data, RST seems a better system as the most frequently used files, whatever they are, are available for fast access. Working on some code? Visual Studio and my project files are cached, shift to some 3D work? Cool, when it’s used, Blender and its files are put in the cache, all the while parts of windows that aren’t used are still available but not taking up expensive, fast SSD space (has anyone actually looked at the help file for MS Paint?). The system’s not perfect – things will only be cached the second (or more, depending on how the driver assess the “frequently used” nature of files) time they are accessed. Also as this is (at least partially) done in the software of the driver, there’s obviously an overhead on the running of the system, however overall it struck me as a good idea and pushed me into purchasing a SSD (a 128GB Crucial M4) to see if they really did transform the performance of my system as much as I’d been led to believe.
My initial plan was to have two 1TB mechanical drives, with a Windows 7 installation on one, with RST accelerating it, a Linux installation on the remaining space of the SSD, with a software RAID setup using the remaining space for my /home partition to hold data and local applications.
Installing Windows and activating the RST was a reasonably straightforward process, with a couple of observations:
- Both the SSD and the accelerated drive must be on the SATA 3 ports of the motherboard (and the SATA 3 ports of the chipset, any additional ports added by a third party chip on your motherboard won’t do).
- Despite saying that you can accelerate “a drive or volume” with RST, I was unable to apply it to a RAID volume setup in the BIOS. This may be due to the RAID setup requring to use a SATA 2 port, but may simply mean that RST cannot be used on RAID volumes.
- RST allows you to use either 18GB or the maximum space (either 64GB, or the full capacity of the drive, whichever is less) for cacheing, there is no fine tuning options.
- Put Windows on a separate drive, I had a spare 250GB drive, which should be plenty for my requirements for the moment. I found that the conflicts between the mdadm style of RAID and the dmraid system were just too big to deal with.
- I started with a copy of Debian Stable with an backported 2.6.39 kernel (this was necessary to use many features of the Sandybridge chipset – even the Ethernet adapter wouldn’t work with the stock kernel) from the Debian-Installer backports archive. (Note this is a very useful archive for anyone who is keen to install Debian on more recent hardware than the standard stable supports.)
- At this point, I had a system that would detect the spare space on the SSD and install to it, but failed to install Grub2. This caused me much frustration, And I was unable to progress for some time.
- I then managed to boot a live disc of the latest *buntu release (11.10) with a 3.0.x kernel, once I had done this and apt-get installed dmraid, I was then able to see my new Debian installation on the SSD. (However when I had tried this trick to install using a *buntu disc I was unable to make the SSD partition appear in the installer.)
- I then managed to open my Debian installation by opening a terminal and running the following:
- dmraid -ay
- mkdir /myraid
- mount /dev/md0 /myraid
- mount –bind /dev /myraid/dev
- mount -t proc proc /myraid/proc
- mount -t sysfs sysfs /myraid/sys
- chroot /myraid
- apt-get install mdadm
- I then had a bootable system, and thanks to a Super Grub 2 Disc I was able to detect the system and boot into my new system. I then installed grub on the disc that was not part of the acceleration setup and told my BIOS to use that as a primary boot device. However there was one final hurdle in that the initial boot image would not automatically recognise my SSD partition as it did not understand it as a drive. I was able to boot my system by entering “dmraid -ay” at the initrd prompt then “exit” to continue booting. I ended up forcing the assembly of all RAID devices at boot time with a little playing around with the image by editing /usr/share/initramfs-tools/scripts/local-top/dmraid and adding the command “dmraid -ay” to the script. Running mkinitramfs then reassembled my initial boot image, and I was able to boot both Windows and Linux.