2

I have the following configuration:

     PV         VG       Fmt  Attr PSize    PFree Used
  /dev/sda3  fedora00 lvm2 a--   222.37g    0   222.37g
  /dev/sdb1  vg0      lvm2 a--    <5.46t    0    <5.46t
  /dev/sdc1  vg0      lvm2 a--    <3.64t 3.29g   <3.64t
  /dev/sdd1  vg0      lvm2 a--  <465.76g    0  <465.76g
  /dev/sde1  vg0      lvm2 a--  <465.76g    0  <465.76g
  /dev/sdf1  vg0      lvm2 a--  <465.76g    0  <465.76g

The problem is I would like to remove /dev/sdf1. When I execute pvmove it says not enough extents. Something doesn't add up because there is lots of 'free' space in the group -

/dev/mapper/vg0-personal   10793808 3037966   7293737  30% /personal

Google tells me the method is pvmove then vgreduce but I don't get far with these. How do I tell it to move any data on that drive and decommission it?

Thanks

2

When I execute pvmove it says not enough extents.

Well, there aren't any, and free space in filesystems doesn't count.

/dev/mapper/vg0-personal   10793808 3037966   7293737  30% /personal

This is a filesystem 10793808 blocks large, 3037966 blocks used, 7293737 free, 30% used. So there is free space but that's filesystem free space, not LVM free space.

The filesystem is still 10793808 blocks large, and that'll be how large the /dev/mapper/vg0-personal LV is and how much space that LV occupies in the LVM at minimum (unless you're using specialties like thin provisioning).

You seem to have several more of such LVs and as a result your VG is pretty much full:

  PV         VG       Fmt  Attr PSize    PFree Used
  /dev/sdc1  vg0      lvm2 a--    <3.64t 3.29g   <3.64t
  /dev/sdf1  vg0      lvm2 a--  <465.76g    0  <465.76g

Your /dev/sdf1 is ~465G (PSize) and the only PV with non-0 free space is /dev/sdc1 with only ~3G (PFree). As such there is next to no free space in that VG. In order to remove /dev/sdf1, you'll have to free up another ~462G somehow.

If you have free space inside your filesystems, that's great, but LVM does not care about that. LVM cares about the size of the logical volumes / block devices it manages, not whatever you decided to store on top of those block devices.

So in order to proceed, you'll have to shrink filesystems, or remove filesystems altogether, or switch to thin provisioning (risky in many ways), or decide to leave things as is after all and not remove a drive.

In any case, make sure to have good backups of your data.

0

To expand on frostschutz answer afaict you have free space in the filesystem rather than in the volume group, to move it across you need to do something like the following (I left a generous margin when resizing, probablly not strictly nessacery but better to err on the side of leaving free space than cut a volume too short because of the rounding error, these steps also assume you are using an ext2/3/4 family fs

umount /personal
resize2fs /dev/mapper/vg0-personal 400G
lvresize /dev/mapper/vg0-personal -l 410g

(the lower case g on lvresize is important, if you use a capital G then lvresize will assume decimal gigabytes)

Unfortunately I don't think you can do this without downtime, the ext filesystems support online growing, but I don't think they support online shrinking.

You should then have the free extents you need to remove the drive.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.