Re: Moving LVM volume?
On Thu, Jan 1, 2015 at 10:54 AM, Frank Miles <fpm@u.washington.edu> wrote:
> I recently added a new hard drive to my home system. I decided to use it
> to create an all-new bootable 'jessie' system.
Okay, what is the old drive doing right now?
> I created a partition
> table that I thought would be flexible:
Well ...
> /dev/sdb1 / (root) {7G}
I do largish roots just in case, myself. But, ...
> /dev/sdb2 /swap {4GB}
> /dev/sdb3 /oldjunk {1G}
Is that all the oldjunk you've got?
And why do you copy it here instead of accessing it from your old disk?
> /dev/sdb4 extended {remainder}
> /dev/sdb5 LVM {one large volume}
Does /dev/sdb5 fill /dev/sdb4? If so, that's not very flexible.
Is the LVM physical volume in /dev/sdb5 all allocated to partitions?
If so, that's not very flexible, either.
I personally don't bother with LVM lately, tend to just use the "DOS
extended" partition and "DOS logical partitions inside that, but I
guess I have developed a sense of how big my partitions should be. LVM
was useful when I was messing with that. (And I generally did not
bother with a DOS extended partition, just put the LVM physical
partition straight on a DOS base partition.)
My workstation partition sizes, BTW:
/ gets 6G or so, just in case systemd or udev or some other newfangled
junk keeps /var/log from mounting before huge amounts of logs are
generatated, or other things that the cabal can't seem to think of
ahead of time happen.
/usr gets 30G or so, because I sometimes load way too many packages.
If one is sensible about the number of packages loaded, 12G should be
plenty.
But the cabal says that's a no-no now, the world is known to be flat,
so we must put /usr in / . So add those together and make one
partition for / and /usr.
/tmp gets 5G or so, /var gets 5G or so, /var/tmp gets 5G or so,
/var/log gets 8G or so, and /var/cache gets 20G or so. The cabal says
we must rely on their in-RAM temporary file system now, so 30G for
/var should be enough. (Pretty soon, they're going to get bit by the
logging conundrum and decide that /var must not be separate. If they
are going to claim to be the new pantheon of Linux Is Not Unix Xtupid,
I wish they'd learn that engineering isn't just pouring all the parts
into the pot and feeding the mess to the homeless. But I'm not
supposed to say things like that.)
Again, if one is sensible about packages, and especially if one
refrains from upgrading (as from squeeze to wheezy) from cache. 8G is
plenty for combined /var. Just clean your /var/cache and /var/log on a
regular basis.
I like to have a separate /usr/local, but in debian, it's not really
necessary for most people. 2G for it gets me by just fine, anyway.
/share/DOS gets whatever seems useful, 1/2G or 5G or such.
/home does not get the rest. I usually give about 30G to /home and
leave the rest un-allocated, for various unexpected stuff that
happens.
And that's what I call flexible.
On small (old) systems with 20G HD, it looks more like 1G to /, 2G to
/tmp 4G to /usr, 4G to /var, 4G to /home, and /share/DOS is a USB
drive. And leave what I can un-allocated, for emergencies. (5G to
combined / and /user, if I'm paying lip service to the cabal. But I'm
planning on skipping jessie, so, ....)
> Most of the partitions- /usr, /home, /var, ... were in LVM2.
Again, did you leave any unallocated space?
> What I've learned since then is that /usr seems to have special
> status,
Uhm, yeah. The great Lennart Poettering and his genius friends really
don't want you to do the separate /usr schtick any more. If you do,
they want you to pre-mount the essentials from /usr in a RAM file
system while it boots.
No, they don't think having a /essentials/bin which would remain part
of the / file system is a good idea. That sounds too much like the
reason for having /sbin and /bin separate (and, by extension, /usr
separate).
> and probably shouldn't be part of LVM as certain tasks
> early in the boot process can't seem to access the interior of
> LVM.
On wheezy, I'm still okay with that. But systemd didn't take wheezy over.
> I've moved 'oldjunk' into the LVM, and want to expand this
> partition to become the new /usr.
I think you're painting yourself into a corner that way. Can you
afford a USB stick or SD card?
> I've shrunk the LVM, but
> the freed space is all at the far end of the LVM.
That's not a problem. This is LVM, after all.
> I have
> been unable to move it towards the end of the disk space,
> so I can expand /dev/sdb3.
Oh. That is a problem.
> gparted, resize2fs, pvmove,...
> (running from a CDROM-based rescue disk) have all failed.
And you're glad they did, really.
> Is there some method that I've overlooked?
Ask yourself, "What do I need to keep?" (Should be mostly stuff in
oldjunk and /home.)
Make sure you have a copy of that somewhere, and just re-partition the
new disk. That's the safest way.
If you are game for a litle exciting ride, after you back up what you
can't afford to lose (See, I'm warning you ahead of time! And note
that you really want to make sure you have a backup copy any way you
do this.), after you make your backup:
Do you have the GUI LVM tool loaded? I would not do this from the
command line. Too many things to forget, and the graphical UI helps
you keep things straight.
Are all your logical volumes in the LVM physical volume fairly fresh?
If so, shrink the one closest to the start of the physical volume
first. Then shrink the second one and move it down. Then the third
one. Make sure the shrunk size is still more than half freespace in
each one as you shrink it, and remember you're still playing a
statistical game here. The more you've deleted and added files in each
partition, the greater chance shrinking it clips off a chunk of an
allocated file.
If you can get more than half the LVM physical freed, reboot and do a
read-only fsck on the entire file system. If it says you have errors,
drop back and punt. Just re-partition the whole disk and restore your
data from backups. If fsck doesn't pick up errors, you may be okay.
At this point you have to boot a live CD or live USB or something
(maybe the old OS on the old drive?) and shrink the DOS logical
partition inside the extended partition. (Shrink /dev/sdb5. I think
that's a separate step, anyway, IIRC.) Then you can shrink the DOS
extended partition (/dev/sdb4) and move it.
You really do not want to do it this way. You could still end up with
some uncought errors that slowly corrupt your file system. Just back
up your essential stuff, wipe the rest, re-partition, and re-install.
--
Joel Rees
Be careful when you look at conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself, as well.
Reply to: