2

A while back I pulled some spare parts to set up a test for backuppc. Two largish hard drives were merged into a single volume with LVM. A few months later, it seems that the second drive is going/gone bad. Last I checked, the data I have would just fit on the first drive, if I could convince the filesystems to resize.

I setup the filesystem as reiserfs, following some reports that it worked well for backuppc. I started using resierfsck to see how extensive the damage was, including trying --rebuild-tree with a badblock list (from the badblocks program). But every time I run, it finds a new bad block and halts, so it looks like the disk is a lost cause.

resize_resierfs tells me that I need to run reiserfsck --check first, even with -f. That in turn tells me it can't run because of an incomplete --rebuild-tree.

At least the data is only backup, so nothing vital would be lost by starting over, just a lot of time downloading initial backups.

Justin Love
  • 554
  • 3
  • 9
  • 18

5 Answers5

3

What you're really trying to do is get the logical volume off of that drive, and your best bet for that is to migrate the physical extents to another disk. There's no way to predict where the free space will come from if you simply resize the filesystem.

Assuming the failing drive is /dev/sdb and the new drive is /dev/sdc, here's the procedure:

Prepare the new disk 

pvcreate /dev/sdc

add it to the volume group

vgextend myvolumegroup /dev/sdc

move the data to the new disk

pvmove /dev/sdb /dev/sdc

note: pvmove is slow, so you may want to do

pvmove -v /dev/sdb /dev/sdc

instead.

Adam Lassek
  • 492
  • 1
  • 8
  • 18
  • Good idea, but I might have to juggle some things to get a free controller and perhaps skip case mounting until old drive is removed. I'd also have to request to purchase a new drive, since none of the spares are as large. – Justin Love Jun 11 '09 at 21:35
  • After the LVM operations, I had to use the reiserfsck options --rebuild-sb and --rebuild-tree, on two separate runs, but this seems to have worked. A lot of files ended up in lost+found, but a large number appear to have been salvaged. – Justin Love Aug 27 '09 at 14:23
  • Glad to hear it. I've never had to do this with a failing drive, the process is usually pretty simple. – Adam Lassek Sep 08 '09 at 16:49
2

Use pvmove to move all the extents for that LV off onto other PVs in the VG.

joshk0
  • 465
  • 2
  • 5
1

I agree that the disk seems a lost cause. Your approach (shrink filesystem, shrink LV, move off bad disk) also seems ok.

This might (and I mean might, all bets are off with a failing disk) work:

  1. Get another disk, at least as large as the failing one.
  2. Add it to the volume group (pvcreate, vgextend).
  3. Move the LV off the failing disk (pvmove).

This will work at the PE/block level, bypassing the filesystem. But you're getting read errors, so I don't know if it will work or fail.

pgs
  • 3,471
  • 18
  • 19
1

with healthy disks, the drill to remove one from a VG is like this: (i'm guessing that you have a single LV spanning both disks)

  1. resize filesystem
    • resize LV
    • pvmove
    • vgreduce

but your main problem seems to be that steps 1 and 3 really won't like disk errors.

in the past, the only way I've recovered data from a reiserfs volume with bad sectors has been ddrescue. all the 'risky' reiserfs tools err on the safe side: at the first disk error, the whole operation is cancelled. with ddrescue i could simply copy to a good device and go on with the reiserfsck.

Javier
  • 9,078
  • 2
  • 23
  • 24
0

Every partition resize program (gparted, Partition Magic, etc) I have ever used performs health checks on the file system before committing any changes. Unless anybody knows of an app that does not and still supports reiserfs, your best bet is to start from scratch. Any other avenue I can think of would be much more work and take much longer.

Otherwise, you can try remapping all bad blocks through the filesystem tools, but if the drive is really going fast they may appear faster than you can remap them.

Joshua Nurczyk
  • 738
  • 6
  • 17