What is Hitachi thinking?

For years now, whenever I’ve had drive or controller problems, I’ve hauled out IBM’s DFT (Drive Fitness Test), even if the drive isn’t a DeathstarDeskstar. Now IBM’s drive division belongs to Hitachi, but DFT lives on. I used it last week to make sure my new colo box could handle the sorts of loads I wanted to put on it. But now that I have my old colo box back, I want to test it to see if the problems I was having might be fixed with a new drive cable before I sell it on eBay.

But this box doesn’t have a floppy. No problem, I thought, the Hitachi site has a bootable CD version. So I downloaded it and burned it and booted with it. But the first thing it does it scan the IDE controllers, and when it’s scanning “Secondary Slave”, it suddenly starts spewing errors about being unable to read A:\COMMAND.COM. Evidently DFT needs to read its own disk just at the moment that the drive was disconnected for scanning. So when they made the CD ISO, they didn’t actually test it, or didn’t think about how it works, and instead of using the “Linux Live CD” model where they make a ramdisk and load themselves into it, they just made a DOS boot partition on the CD and expect it to be there all the time.

I guess it’s off to my junk shelf to see if I have a floppy drive and cable.

That was easy

I needed to re-arrange some disk space. I explained the situation in Rants and Revelations » Why didn’t I use LVM on everything? with a table showing the current layout and everything. At the time, my plan was:

  1. Migrate the content of /dev/hdc3 off using “pvmove” and “vgreduce”.
  2. Delete all three partitions on /dev/hdc3 and add it back to the vg using “pvcreate /dev/hdc; vgextend xen-space /dev/hdc”.
  3. Migrate the content of /dev/hde2 off using “pvmove” and “vgreduce”.
  4. Delete the /dev/hde2 partition and increase the disk of /dev/hde1 to fill up the drive, and use resize2fs to make /dev/hde1 use the whole partition.

I did steps 1-3, and it all worked perfectly. I didn’t have to shut down anything, and it didn’t interrupt the normal operation of either the dom0 or the domUs. But when I’d done that, I realized I actually had enough free space on the lv that I could do an even better plan:

  1. Set up a 250Gb lv.
  2. Use rsync to copy everything from /dev/hde1 to the lv.
  3. Once that was done, shut down domU 1.
  4. Make /dev/hde1 part of the lv.
  5. Make the 250Gb lv bigger using lvextend– I chose to add 100Gb to it, and I have space to add more if I need it.
  6. e2fsck -f” and “resize2fs” the lv.
  7. Restart the domU 1, using the lv instead of /dev/hde1.

This worked perfectly. The domU was down about 10-15 minutes tops. /dev/hde is still partitioned into two partitions, even though both partitions are part of the same vg. But other than that, it’s exactly what I’d have done if I were setting it up from scratch now.

Why didn’t I use LVM on everything?

Due to a series of historical accidents, I have the following disk space layout:

Partition Size Use
Disk 1 – 250Gb
/dev/hda1 2Gb dom0 root
/dev/hda2 2Gb dom0 swap
/dev/hda3 Rest part of vg “xen-space”
Disk 2 – 250Gb
/dev/hdc1 2Gb formerly dom0 root – unused
/dev/hdc2 1Gb formerly dom0 swap – unused
/dev/hdc3 Rest part of vg “xen-space”
Disk 3 – 400Gb
/dev/hde1 300Gb mounted as /dev/hdb on a domU
/dev/hde2 Rest part of vg “xen-space”

The root partitions of the three domUs are all lvs on vg “xen-space”. There is over 250Gb free on the vg.

What I would like to do is clean up the second drive to get rid of the extraneous partitions, and to grow the partition on /dev/hde1 to the full disk. So what I’m thinking of doing is the following:

  1. Migrate the content of /dev/hdc3 off using “pvmove” and “vgreduce”.
  2. Delete all three partitions on /dev/hdc3 and add it back to the vg using “pvcreate /dev/hdc; vgextend xen-space /dev/hdc”.
  3. Migrate the content of /dev/hde2 off using “pvmove” and “vgreduce”.
  4. Delete the /dev/hde2 partition and increase the disk of /dev/hde1 to fill up the drive, and use resize2fs to make /dev/hde1 use the whole partition.

The problem is that I don’t know if I can do this stuff without shutting down the domUs. And for the physical partition /dev/hde1, which is mapped to the /dev/hdb on one of my domUs, I don’t know if I have to shut down the domU or just umount it within the domU and remount it afterwards.

That was relatively painless

The box is up. It was only offline for about 20 minutes, tops. Everything seems to be working. Fingers crossed.

I officially love LVM. And I wish my big binary file archive was on LVM, because it’s getting nearly full and I want to expand it. Of course, any changes in it will probably require shutting down because of the way the file system is mounted through Xen.