On May 7, 2007, at 12:56 AM, Wojtek.Pilorz wrote:
On Sun, 6 May 2007, Scott Lamb wrote:
Date: Sun, 6 May 2007 13:47:28 -0700
From: Scott Lamb <slamb@xxxxxxxxx>
Reply-To: CentOS mailing list <centos@xxxxxxxxxx>
To: CentOS mailing list <centos@xxxxxxxxxx>
Subject: Re: Re: LVM Resizing Problem
On May 6, 2007, at 8:14 AM, Ross S. W. Walker wrote:
LVM even warned you --IN CAPS-- "THIS MAY DESTROY YOUR DATA".
I guess it was right. I haven't had much luck with reducing a
volume below its
initial size. I usually make a new LV and rsync or cp -a the
data over to it.
I try to leave some free space just for this. Or add a drive
temporarily.
Were the LV calculations done in the VG's extent size unit?
Most people forget LVM rounds to the closest whole extent in it's
calculations which I believe is 4MB by default, so care must be
taken to make sure any file system fits comfortably in there
first.
Is there any tool which is aware of both the filesystem and LVM
layers and can correctly ensure the filesystem fits?
no tool as such I am aware of, but bc is your good friend.
Use lvdisplay rather than lvs, pvdisplay,. etc and count in LE
(logical
extents) rather than MB or GB.
Okay. I will just do that carefully.
Shawn, thanks for the system-config-lvm suggestion. I don't think it
will be too helpful in my specific situation (probably not available
from the rescue disk), but it's good to know about in general.
The filesystem on my only large disk array is corrupt, presumably due
to some problem in one of the Fedora Core 6 update kernels. I
rebooted into single user mode, fscked (which found a huge number of
errors) and rebooted and it's still complaining. So it's time to
start over with a fresh filesystem on a more trustworthy dom0 system
(CentOS 5). I don't have anything vital stored only there, but there
are a number of large files I'd like to save if possible. They don't
fit anywhere else.
Here's my plan:
1. boot a CentOS 5 DVD in rescue mode, fsck the filesystem again
2. shrink the existing filesystem and LV (crossing my fingers)
You canno shring ext3 until it fsck clean, as far as I remember.
I think fsck reported the filesystem as clean...the kernel was still
comparing though.
3. install CentOS 5 to a new LV and filesystem
4. copy whatever's left of these files
5. delete the old LV
6. expand the new filesystem and LV
Never done steps #2 and #6 before, and I want to give it as much
chance of success as possible with an already-screwed-up filesystem.
I would suggest you to add external HDD (e.g. USB2, or IDE/SATA with
USB2/PATA+SATA converter) and copy your data.
If the filesystem is screwed up, resizing can only make its state
worse.
Definitely a more reliable way, but I don't want to spend money on
this project. If I lose the files, life will go on.
I see the section in the LVM HOWTO [1], but it doesn't mention the
sort of gotcha you're describing. I'm skeptical of LVM's
documentation in general. It doesn't even mention RAID (md), instead
including some incredibly stupid recipes virtually guaranteed to lose
all your data when one disk out of many fails [2].
Could you please elaborate or give some pointers about reasons for
those
recipes being stupid, etc. ?
Sure. In the "add disk" recipe:
* the "dev" volume group will fail if /dev/sda, /dev/sdd, /dev/sdf,
or /dev/sdg fail.
* the "sales" volume group will fail if /dev/sdb or /dev/sde fail.
* the "ops" volume group will fail if /dev/sdb or /dev/sde fail.
LVM does not do RAID, so adding drives makes failures more likely.
I brought this up on the LVM list [3]. One person came up with a nice
recipe on how to use LVM+RAID, but there wasn't a consensus that it
would be good to stop misleading people into destroying their disks.
[1] - http://www.tldp.org/HOWTO/LVM-HOWTO/reducelv.html
[2] - http://www.tldp.org/HOWTO/LVM-HOWTO/recipeadddisk.html
[3] - http://marc.info/?l=linux-lvm&m=115879450212535&w=2
--
Scott Lamb <http://www.slamb.org/>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
