February 2010 Archives

My Intel 80 GB X25-M G2 in my laptop died recently. Everything was running smoothly when I shut down but when I powered back up the BIOS couldn't see the drive any longer. Fortunately, I keep pretty good backups and I was up and running on a spare platter drive relatively quickly.

The RMA process was pretty disappointing. Phoning Intel was the only option.

I called in the afternoon on Monday, February 1, since they are only available during business hours. My time on hold was pretty short, probably about five minutes and it took less than 10 minutes to get the RMA rolling. I was told I'd receive an email shortly with RMA instructions.

I didn't receive an email. At that point it was after business hours so I used their web based form to submit a question. I included my RMA and case numbers, and I never heard back from them.

At this point there is a delay that is completely my fault. I didn't get a chance to call back until a week later on Monday, February 8. It turned out they got my email address wrong. I pronounced my email address and I spelled it to them letter for letter. They didn't only have it wrong, they were short on characters...

I was happy with the turn around time on the package. I had the drive at the post office on Tuesday, February 9 and the new drive arrived at my door on Tuesday, February 16.

The night of my second call to Intel I realized there was a pretty good chance they also didn't get my address correct. They do not include your shipping address in the RMA email. This time I sent an email to the address listed in the RMA email which is rma@mailbox.intel.com. I never heard anything back.

My Overall Opinion

I was happy with the service once I was able to get to the point where I was able to ship the drive out. I'm generally unhappy with their telephone support, and I am extremely disappointed with their email communications.

I Sure Did Miss the SSD

Certain tasks were noticeably slower. Most of the time the performance difference isn't something you can feel but some disk intensive tasks are significantly faster with the SSD. Things like booting, installing and updating a large number of packages with apt, and importing photos into F-Spot are at least twice as fast with the X25.

The thing I noticed most was the heat. When I first moved from the old hot platter drive to the X25 I didn't think the difference was so dramatic. Running on the SSD for months sure made the platter drive feel scary hot. The SSD is warm underneath the laptop where there is only piece of plastic covering and physically touching the drive.

The platter drive even made the top of the laptop very warm to the touch. The difference in temperature is huge.

Update: The replacement drive died in the middle or April 2010 (about 3 months later). It died in a different make/model laptop (HP dv8t), but under similar circumstances. The drive was fine when the laptop was cleanly shut down, the BIOS could no longer see the drive on next boot. The replacement-for-the-replacement has been running fine since then, it is now September 2010.

I'm starting to get impatient. I really want to start running a next generation file system. I'd like to have easy to manage sub volumes, block level checksums, and RAID-like redundancy at a higher level.

Writable snapshots are what I'm most excited about, though. Snapshots of my home directory will help protect me from accidental file deletions and modifications between backups.

I'm currently saving disk space with my QEmu disk images by juggling cloned qcow images. It should be much easier to manage some writable Btrfs snapshots instead. Deduplication would likely save me quite a bit of space as the virtual machines age. ZFS already has deduplilcation but it sounds like deduplication won't be all that far away for Btrfs.

What are the Best Practices for a Btrfs Root File System?

I have absolutely no idea, but I think I am on the right track. I did not want to use the root of the Btrfs file system as my / file system. I created a sub volume called rootfs instead. I mounted that sub volume as / and I mounted the entire Btrfs volume under /mnt/btrfs.

Doing it this way felt pretty well organized. From this point it would be pretty easy to create a homefs and a tmpfs. I didn't want to break out /var/ or /usr. That would make it too difficult to snapshot the operating system between upgrades.

Overview of How to Get it All Up and Running

There is a tool to convert and ext3 or ext4 file system to Btrfs. I didn't use them and I don't know if they would allow me to lay out the file system the way I was hoping. I ended up doing it the long way.

This isn't going to be a step by step guide. The quick overview of the steps was:

• Install Ubuntu 9.10, small ext2 or ext3 boot partition
• Compile and install kernel 2.6.32 and the latest btrfs-utils (you can skip this if you don't need snapshot removal)
• Add btrfs.ko, zlib_deflate.ko, and crc32c.ko to the initramfs
• Backup everything on the / file system
• Create a Btrfs on the old / block device, create a rootfs sub volume
• Restore the old / file system contents to the rootfs subvolume

GRUB and fstab

You'll have to change your root kernel parameter and add a rootflags parameter:

root=/dev/sda2 rootflags=subvol=rootfs

I left fstab just pointing to /dev/sda2. That seemed to be work fine and allowed me to boot from different snapshots. I also added a line to mount /dev/sda2 under /mnt/btrfs.

Snapshotting and Booting from a Snapshot

I created a snapshot of rootfs called rootfs-1 and then I performed an apt-get dist-upgrade and installed a few extra packages. It wasn't a huge change but it was enough to test booting from a snapshot.

Booting from a snapshot turned out to be easy. At the start of boot I chose to edit the GRUB entry before booting. I just changed subvol=rootfs to subvol=rootfs-1. It would probably be pretty easy to automatically generate a GRUB menu with all the snapshots as options.

One Little GRUB Hiccup

update-grub ran fine the first time, while my root filesystem was still ext4. update-grub got angry and wouldn't update properly with a Btrfs root. I don't have a good fix for this yet, I just kept fiddling with the GRUB entries during boot.

GRUB, Btrfs, and Kernels

Being able to snapshot root will be very handy. I'd be tempted to set up some automation to snapshot root every day and at every apt-get upgrade.

Unfortunately, GRUB doesn't understand Btrfs or its snapshots. Kernels and initrd images have to be stored on a boot partition that won't support snapshots. That makes the kernel the weak link in the upgrade chain.

It would be nice if the boot loader could pull a kernel straight from the snapshot. That would let you keep your snapshots more self contained. I don't feel this is very important, though. Snapshots of root alone will be a huge step forward.

Sorry for the Lack of Screen Shots

My X25 died this week and I didn't get around to backing up my Btrfs virtual machine. I didn't think I would need to back up that image because I was planning on deleting it after I wrote this article.

I am seriously considering giving Btrfs a try on my laptop when the replacement X25 gets here. I will post some screen shots if I do.