2

I know variants of this question have been asked before, but I couldn't find a specific answer to my situation. So here goes:

Running ubuntu server 12.04 with the os on a separate drive and two 1,5 TB WD Green drives (sdc and sdd). The 2 WD greens make up a volume group using all the available space and this makes up a logical volume of the same size. One of the drives (sdd) are getting old, and I'm planning on replacing it. I have bought a WD Red 4 TB (sdb) drive on which I have managed to create a partition using the gpt partition table. I have added this drive to the volume group (/dev/storage) and logical volume (/dev/storage/storage (not ideal nomenclature, I know, but I didn't set this up to begin with)) and resized the file system using resize2fs (completed after 18 hours) so that all the space on the 3 drives are available. I'm using webmin from time to time (as well as the terminal), and I got the impression that one could tell the system to move all the contents from one drive to another one, but no luck. Getting error message telling me "No extents available for allocation".

So this is where I'm stuck at the moment. I would really like some advice on what's the easiest way to make sure all my files on the oldest 1,5TB drive is moved to the new 4TB drive (or at least off the oldest one), so that I can remove the old one completely.

From what I've read, I need to reduce the filesystem, then reduce the logical volume freeing enough space on my new drive to fit the files from the old one. Do I have to run lvreduce -L3T /dev/storage/storage followed by resize2fs to scale it down first? And then what? pvmove?

Another solution might be to just create a new volume group and logical volume using the new 4TB drive, mount it, move everything from the old lv to the new one, and then remove the old lv and vg?

I feel I have tangled myself into something I don't know the best way out of. Any input is greatly appreciated.

3
  • Any reason not to setup sdb with a new vg set up to your liking, then move all the data there and reinitialise the good old drive into the new vg. You can get rid of the /dev/storage/storage name that way, and are sure the data is not on the drive you are going to retire.
    – Anthon
    Commented Mar 14, 2014 at 15:38
  • If you're going to reduce the size, resize the filesystem before shrinking the LV (opposite of what you do to enlarge). That's an offline operation AFAIK, btw, no idea how long it would take. Backup/restore might be faster. (If you hadn't resized the FS or LV, just added the new disk to the VG, you could have removed the old disk without downtime.)
    – Mat
    Commented Mar 14, 2014 at 15:42
  • Could you clarify what exactly you need? Is the problem moving the data? Resizing the volume? How exactly are you moving the data?
    – terdon
    Commented Mar 14, 2014 at 15:43

1 Answer 1

3

You started with:

 -----------
| VG storage|
|-----------|
| LV storage|
|-----------|      -------------
| pv0 | pv1 |     | new         |
| 1.5 | 1.5 |     | 4.0         |
 -----------       ------------- 

Let's say physical volume 0 (pv0) is the one you want to get rid of. What you need to do is extend the volume group (VG) to include the new drive:

 -------------------------
| VG storage              |
|-----------+-------------|
| LV storage| FREE EXTENTS|
|-----------|-------------|
| pv0 | pv1 | new         |
| 1.5 | 1.5 | 4.0         |
 ------------------------- 

Note that extending the volume group (with pvcreate and vgextend) leaves you with the free extents that you need for pvmove. Instead, you extended the logical volume (LV) to occupy all the free extents.

To recover, you need to first shrink down the filesystem (which has to be done offline, and may well take a while) and then shrink down the logical volume. Finally, you can do the pvmove (which can be done online) and the vgreduce.

It essential that you not shrink the logical volume shorter than your filesystem; doing so will lead to data loss. The easiest way is to use the -r option to lvreduce, which will handle resizing the filesystem for you.

In summary:

  1. umount /dev/mapper/storage-storage
  2. lvreduce -r -L3G storage/storage
  3. long wait
  4. You can remount the storage now if you'd like.
  5. pvmove /dev/sdd1 (or whichever is the old disk)
  6. vgreduce storage /dev/sdd1
  7. Now you can lvextend storage if you wish. You can use -r here, too.

PS: Keep in mind what the failure curve of HDDs looks like: A bunch at first from manufacturing/shipping/etc. issues, then very few, then finally an increasing amount as the drive gets old. Your new drive is in the initial break-in failure period.

PS(2): vgrename and lvrename do exist...

PS(3): Are you sure you don't want to mirror the data? Another 4TB drive isn't that expensive.

2
  • Thanks a million. Maybe mirroring is the way to go. Can I use your method above to move stuff over to the new drive, remove the two 1,5TB drives, and then when the second 4 TB drive arrives, type in some fancy command that mirrors the first 4TB onto the second? Also, you wrote lvreduce -r -L3G. Do you mean -L3T?
    – GeGiggedy
    Commented Mar 14, 2014 at 18:15
  • @user62759 yes, you can. You've have to pvmove off of the other 1.5TB drive too, of course. The fancy command appears to be lvconvert -m 1 --type raid1 storage/storage (that's from reading the docs, I've never tried it...). [You could also use md below LVM, instead of integrated into it, which is what I've done before, the integration into LVM is fairly new. You'd do this by creating a degraded array on the new disk, pvmoving the data over, then vegreducing the first disk out. Then add it to the array. Far more chances for error in this method.]
    – derobert
    Commented Mar 14, 2014 at 18:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .