To improve the performance of amber, I bought another 4GB of memory and a 250GB SSD (Samsung 840 Series), a 2.5" form factor. Since I'd run out of 3.5 hard drive bays, I had to buy a 5.25" to 2.5" adapter in order to mount the SSD in the case.
I planned to install a fresh Windows 7 on the SSD, figuring I knew all the pitfalls from my previous messing about with disks. However, as usual, there were some new learning experiences.
First, there seems to be no logic in how the motherboard detects and orders the hard drives. While it is possible to control the order of disks for grub, by specifying the boot order in the BIOS, Linux identifies the disks in the sequence detected by the BIOS. With the SSD connected, the BIOS disk order was:
I cannot figure out how this order relates to which SATA ports the disks are physically connected to. Maybe it is just how the disks respond to the initial probes.
The first problem was that the mirrored drives in Debian now had
different device identifiers, sdb
and sdd
had
become sdc
and sde
, respectively. The mirror
array was not built. To fix this, I used the UUIDs of the drives in
the mdadm.conf
rather than the OS identifiers. This was
performed with the following commands:
# mdadm -Ebcs partitions # scan for arrays and display ARRAY directive ARRAY /dev/md0 UUID=50144dd5:53a81d78:173b5c72:0a49ac2c # # test assembly with uuid # mdadm --assemble /dev/md0 --uuid=50144dd5:53a81d78:173b5c72:0a49ac2c
This worked, so I knew it was safe to place the ARRAY directive in mdadm's configuration file.
Here's a summary of the disk organisation:
Disk Type | Usage | Grub | Debian | Windows (HD) | Windows (SSD) | Physical Location | BIOS Designation |
---|---|---|---|---|---|---|---|
WDC 250GB SATA | Windows 7 / Debian Squeeze | hd0 | sda | C: | D: | Lower | SATA:3S-WDC WD2500JS |
SSD 250GB SATA | Windows 7 | hd4 | sdb | G: | C: | 5.25" drive bay | SATA:4M-Samsung 840 Series |
WDC 250GB SATA | Windows Data | hd1 | sdd | D: | E: | Middle Lower | SATA:5M-WDC WD2500JS |
WDC 1000GB SATA | ext3 mirrored disk | hd2 | sdc | N/A | N/A | Upper Lower | SATA:4S-WDC WD10EADS |
WDC 1000GB SATA | ext3 mirrored disk | hd3 | sde | N/A | N/A | Upper | SATA:6M-WDC WD10EADS |
The next problem was getting the Windows 7 boot configuration to play with the GRUB boot. As had happened before, installing Windows 7 overwrote the GRUB MBR, so I had to restore it by booting into Debian via a GRUB boot CD.
I could boot Windows 7 on the SSD by chainloading into hd0
,
but GRUB didn't allow that to hd4
, presumably because there
was no boot sector on the SSD. I rectified this as
described previously, except this time
I used the bcdboot
command to rebuild the system BCD.
I then wanted to edit the BCD files on both instances of Windows 7.
On the SSD it needed one entry, so booting from GRUB would be
direct, while on the old hard drive, I still wanted both entries,
but clearly identified as to which was entry for the SSD and which
was not. First I tried using bcdedit
from the PowerShell
window, but every attempt to set a new value was met with the same
error:
PS C:\Windows\system32> bcdedit /set {default} description "Windows 7 (SSD)" The set command specified is not valid. Run "bcdedit /?" for command line assistance. The parameter is incorrect. PS C:\Windows\system32>
This was deeply frustrating as it turns out this is a problem with Powershell, and works just fine from a Command Prompt window. The next issue was that no matter how I modified the description in the BCD file on the SSD, on boot, it would be the same as before. I finally discovered that the default store (the system store) that bcdedit was manipulating was not on the SSD but on the old hard drive. I had to use this style of command to make the changes I wanted:
bcdedit /store C:\boot\BCD /set {default} description "Windows 7 (SSD)" bcdedit /store C:\boot\BCD /delete {1edd9dcc-f706-11de-8ee9-8fa35a0bc640}
It took me a while to figure out that the partition identifiers in the bcdedit display are relative to the instance that's booted. Now, the BCD on the SSD looks like this (when booted into the SSD):
Windows Boot Manager -------------------- identifier {bootmgr} device partition=C: description Windows Boot Manager locale en-EN inherit {globalsettings} default {default} resumeobject {9cff3092-9941-11e2-b29d-0021855ea9d9} displayorder {default} toolsdisplayorder {memdiag} timeout 30 Windows Boot Loader ------------------- identifier {default} device partition=C: path \Windows\system32\winload.exe description Windows 7 (SSD) locale en-EN inherit {bootloadersettings} osdevice partition=C: systemroot \Windows resumeobject {9cff3092-9941-11e2-b29d-0021855ea9d9} nx OptIn detecthal Yes
While on the old version of Windows 7 it displays as (when booted into the old hard drive):
Windows Boot Manager -------------------- identifier {bootmgr} device partition=C: description Windows Boot Manager locale en-EN inherit {globalsettings} default {default} resumeobject {1edd9dcd-f706-11de-8ee9-8fa35a0bc640} displayorder {default} {1edd9dcc-f706-11de-8ee9-8fa35a0bc640} toolsdisplayorder {memdiag} timeout 30 Windows Boot Loader ------------------- identifier {default} device partition=G: path \Windows\system32\winload.exe description Windows 7 (SSD) locale en-EN inherit {bootloadersettings} osdevice partition=G: systemroot \Windows resumeobject {1edd9dcd-f706-11de-8ee9-8fa35a0bc640} nx OptIn detecthal Yes Windows Boot Loader ------------------- identifier {1edd9dcc-f706-11de-8ee9-8fa35a0bc640} device partition=C: path \Windows\system32\winload.exe description Windows 7 locale en-EN inherit {bootloadersettings} osdevice partition=C: systemroot \Windows resumeobject {1edd9dcb-f706-11de-8ee9-8fa35a0bc640} nx OptIn detecthal Yes
So, was it worth the hassle and money? I timed the duration between boot menu selection and the display of the user login screen:
Boot Device | Boot Time |
---|---|
Hard Drive | 33s |
SSD | 21s |
The SSD cuts boot time by about a third. Not stellar, but nice to have. The other benefit is that program start-up time on the SSD is almost instant, no disk lag at all. Mmmmm, nice!