| 1 |
On Wed, 23 Nov 2011 21:28:56 -0600 |
| 2 |
Dale <rdalek1967@×××××.com> wrote: |
| 3 |
|
| 4 |
> Dale wrote: |
| 5 |
> > Neil Bothwick wrote: |
| 6 |
> >> You have space in the filesystem, but the volume containing that |
| 7 |
> >> filesystem is too large to move. You must first reduce the |
| 8 |
> >> filesystem size, with resize2fs or whatever suits your fs, then |
| 9 |
> >> shrink the LV with lvresize. That will free up enough extents to |
| 10 |
> >> be able to fit them all on one disk. Look at the output from lvs |
| 11 |
> >> to see what is taking up all the space. |
| 12 |
> > |
| 13 |
> > So, me staring at it a while and trying to figure it out did work. |
| 14 |
> > That is what I was thinking. Thing is, it looks to me like it |
| 15 |
> > would just move the stuff over then I can reduce it by what sdb is |
| 16 |
> > making for its share. Although, their way makes sense too. |
| 17 |
> > |
| 18 |
> > I basically need to reduce the thing by 59604 PEs then it can move |
| 19 |
> > them over to sdc so I can remove sdb. Looks like I am about to |
| 20 |
> > really learn something here. It uses ext4 by the way. Looks like |
| 21 |
> > adding is easier than removing, sort of. |
| 22 |
> > |
| 23 |
> > Now to get my ducks in a row. o_O |
| 24 |
> > |
| 25 |
> > Thanks. |
| 26 |
> > |
| 27 |
> > Dale |
| 28 |
> > |
| 29 |
> > :-) :-) |
| 30 |
> > |
| 31 |
> |
| 32 |
> |
| 33 |
> OK. Everyone duck, I been thinking on this and Neils info above. |
| 34 |
> lol This is what I sort of figured out and tell me where I am off |
| 35 |
> here. I have to reduce the file system, change the partition in |
| 36 |
> cfdisk (?), resize the lv, then reduce the vg, then I can run |
| 37 |
> pvmove? After all that, I can remove the drive sdb? Do I have the |
| 38 |
> order correct too? If it does involve all this, I'm not sure I want |
| 39 |
> to do this. The file system and cfdisk part makes me nervous. Maybe |
| 40 |
> some of this isn't needed and I am reading some of the info |
| 41 |
> incorrectly, I hope. |
| 42 |
|
| 43 |
No, not quite. You're on the right track but got some of the details |
| 44 |
wrong. Let's look first at the layers of stuff involved: |
| 45 |
|
| 46 |
|
| 47 |
files & directories |
| 48 |
|
| 49 |
file system |
| 50 |
|
| 51 |
logical volume (LV) |
| 52 |
|
| 53 |
volume group (VG) |
| 54 |
|
| 55 |
physical volume (PV) |
| 56 |
|
| 57 |
physical partition (i.e. /dev/sda1 etc) |
| 58 |
|
| 59 |
physical disk (i.e. something Seagate etc made) |
| 60 |
|
| 61 |
|
| 62 |
|
| 63 |
OK, there's a lot of stuff there. When you made the LV, you worked from |
| 64 |
the bottom up. To undo it, you work from the top down. And the |
| 65 |
important bit: |
| 66 |
|
| 67 |
Everything in that list only knows about the one directly below it. |
| 68 |
|
| 69 |
The other important bit: |
| 70 |
|
| 71 |
Nothing in that list can be bigger than the thing below it. |
| 72 |
|
| 73 |
This makes perfect sense: You can't store a 5G file on a 4G |
| 74 |
file-system, nor can you create a 1TB partition on a 500G disk. |
| 75 |
|
| 76 |
|
| 77 |
Tools like lv* only know about LVs and how they are built, it's |
| 78 |
clueless about the actual files and filesystems involved. So when you |
| 79 |
want to move things around, the tool will look at the volume and see |
| 80 |
how many extents it uses. It will want to move all those extents |
| 81 |
somewhere else. |
| 82 |
|
| 83 |
Now say you made a 40G filesystem on an LV but only have 500M of |
| 84 |
actual files on it. LVM tools are going to want to move a 40G volume, |
| 85 |
never mind that 39.5G of it is unused. If you don't have 40G of free |
| 86 |
space, you have to start juggling. |
| 87 |
|
| 88 |
First get the filesystem down to a reasonable size: |
| 89 |
|
| 90 |
1. Shrink the filesystem using resize2fs, resize_reiserfs etc. |
| 91 |
2. lvreduce to make the logical volume match the file system. |
| 92 |
|
| 93 |
Now you have a 500M thing to move around and your life gets easier. |
| 94 |
|
| 95 |
What you want to accomplish is to move all the LVs from one disk to |
| 96 |
another disk, you need to have enough free space on the new PV to hold |
| 97 |
all those LVs. When you've done that the old PV will now have no data |
| 98 |
on it (none of it's extents will be in use), you can remove it from the |
| 99 |
VG, then delete the PV, and finally remove the disk from the machine. |
| 100 |
|
| 101 |
*fdisk is the only truly destructive tool in your toolbox, the LVM |
| 102 |
tools will all give you errors if you try and remove things that are in |
| 103 |
use or if there's not enough free space. |
| 104 |
|
| 105 |
There's no easy recipes for this that you can just follow. You need to |
| 106 |
understand the things you are dealing with and know what they are. But |
| 107 |
it's not *that* hard. |
| 108 |
|
| 109 |
Like most things in Linux, LVM assumes that you, Dale, are probably not |
| 110 |
a complete idiot and that you do know what you are doing. That's why |
| 111 |
are the gory details are exposed for you to play with. |
| 112 |
|
| 113 |
Now if it were Windows and you were extremely lucky, you might get a |
| 114 |
GUI thingy that let's you drag an bunch of unnamed stuff from here and |
| 115 |
put it there. Which would promptly fail, silently. |
| 116 |
|
| 117 |
|
| 118 |
|
| 119 |
|
| 120 |
|
| 121 |
-- |
| 122 |
Alan McKinnnon |
| 123 |
alan.mckinnon@×××××.com |
Archives