Recently I bought a solid-state harddisk, an Intel X25M. I wanted to use this disk in my Windows development system, without having to do a fresh install of Windows XP. I really didn’t want to install all my applications again, not to speak of all the custom configurations and tweaks I usually apply to Windows to make it palatable. So I thought I’d just make a image copy of my old harddisk to this new one, and be done with it.

There was a small problem, however: the old harddisk had 250 GB capacity and the Intel X25M has only 80 GB. That’s not going to fit. There was only 60G of data on the old harddisk, so the data itself would fit, but the NTFS file system was dimensioned to take the whole 250G. Somehow, I had to shrink the file system so that it would fit on the X25M.

While investigating programs that could do this, I encountered many commercial Windows programs, and also some utilities which worked under MS-DOS when booted from a Live-CD. All these programs work directly on a disk, and I found that a bit too risky. My idea was to make an image of my old Windows file system first, and work on that. If something would go wrong I could always make a fresh working copy from the original image for a retry.

After some more searching I found ntfsprogs in the FreeBSD ports. It contains a ntfsresize program which can shrink or expand a NTFS file system. Just what I needed! Let’s install it:

My next step was to make an image snapshot of my old Windows disk to a file. ntfsclone does just this, with the added bonus that unused sectors in the file system don’t take up any room: the image is stored as a sparse file. When I plugged my old Windows disk into my FreeBSD system, the NTFS partition showed up as /dev/ad2s1. I first cloned it to a file, then mounted this file as a volume and inspected its contents.

# ntfsclone -o ntfs.img /dev/ad2s1

The ‘ntfs.img’ file was about 250G in size, but since it was a sparse file, it didn’t take that much room in reality.

The utility ntfsresize works on devices, not on image files, so I first had to make the image file accessible as a device using the ‘memory disk’ driver.

Now the stage is set to do the actual shrinking. To make sure the resulting file system would fit on the Intel SSD, I shrunk it to 79G. This is a bit on the conservative side; specifying the new size as sectors could optimize the space; probably I’m now wasting some 1G of space on my SSD. Ah well… maybe next time.

After the resize, the imagefile ‘ntfs.img’ stays at 250G, since it’s not automatically truncated. I pulled out the relevant part out of it using ntfsclone for a second time. The –force is necessary because the resize action flags the volume for a chkdsk check.

# ntfsclone --force -o shrunk.img /dev/md0 # mdconfig -d -u /dev/md0

The ‘shrunk.img’ is 79G in size, and I transfered it to the SSD using a simple dd command. Then I shut the system down, connected the SSD to my Windows PC and what do you think? It booted correctly and showed me my good old Windows desktop, albeit with much less free space than before, but three times faster.

Some operations which really benefit from SSD are those which access many files. Compiling large projects fall under this: there are hundreds of include files to read. SSD’s have zero seek time, since they have no moving parts. Also, working with Subversion is a lot quicker. During an update or commit, Subversion checks up to thousands of files on my system, and a SSD really speeds that up.