23 November 2011 by Lars

LVM/disk issues: moving a logical volume, resizing an (unmounted) XFS filesystem

Well, the disks are gone… (actually, two: one a remanufactured – previously replaced – disk in the 3ware RAID5 array – and the other the Crashplan destination for my local machines).

Case 1: 3ware RAID5 array

The disk constantly went online, but did intermittently come back. Solution: replace with the spare I had sitting around. Solved… Gotta love RAID5. Except when two disks in a badly ventilated, overheating case fail.. which hasn’t happened yet…

Case 2: LVM

I had set up a couple of JBODs as a destination for Crashplan. Local and friends’ backups. Because it’s a backup, the destination itself was not raided. On the other hand, I had set it up on LVM. Good thing I did, except… it didn’t help…

So when the disk underlying the volume started to fail, I first tried to add another disk to the volume, and then migrate the disk over. I’ll describe it here, even though it didn’t actually help.

1. Add a disk to the existing volume:

   vgextend  vol-backup /dev/sde1

2. Move the existing logical volume to the new disk:

   pvmove -n crashplan /dev/sdd1 /dev/sde1

3. In theory, remove the old disk from the VG:

   vgreduce  vol-backup /dev/sde1

The reason that didn’t work was that the pvmove aborted at around 3.5% (it can actually pick up again after a system restart – nice!). But the disk was really a goner… So… filesystem lost, will need to put something else in place. But… I just used my spare disk for the RAID5 array. Darn. Well, LVM again to the rescue.

/home lives (right now) on another LVM volume, sitting on a 2TB disk. But I had made the logical volume use up the entire VG. What I wanted was to (temporarily) shrink /home, create a new crashplan LV on it, and then, when I can get a replacement disk, migrate the crashplan volume off.

But: XFS does not allow shrinking. It does allow dump – build – restore, though. So, here’s what I did:

1. Dump the existing (luckily not fully populated) /home into a dump file:

   xfsdump -f /space1/tmp/xfsdump.home /home

2. Rebuild the entire VG, with a 1TB home LV and a 750GB crashplan LV (did this using the GUI…)
3. Restore the filesystem:

   xfsrestore -f /space/tmp/xfsdump.home /home

4. Now we have both a home and a crashplan LV on the same volume. Later, I will be able to migrate crashplan off, in case it is needed.

    # lvdisplay
     --- Logical volume ---
     LV Name                /dev/vol-home/crashplan
     VG Name                vol-home
     LV UUID                jmJ7U8-228d-1Eq6-l2rq-eiHx-PfGz-cqCNtp
     LV Write Access        read/write
     LV Status              available
     # open                 1
     LV Size                788.48 GiB
     Current LE             201850
     Segments               1
     Allocation             inherit
     Read ahead sectors     auto
     - currently set to     256
     Block device           253:7
   
     --- Logical volume ---
     LV Name                /dev/vol-home/home
     VG Name                vol-home
     LV UUID                3dmI1M-764J-gE1v-B1j7-zDiR-85Tq-uAooNl
     LV Write Access        read/write
     LV Status              available
     # open                 1
     LV Size                1.00 TiB
     Current LE             262144
     Segments               1
     Allocation             inherit
     Read ahead sectors     auto
     - currently set to     256
     Block device           253:8

#3ware#Crashplan#LVM#RAID5