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@slamb.org Reply-To: CentOS mailing list centos@centos.org To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] 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:
- boot a CentOS 5 DVD in rescue mode, fsck the filesystem again
- 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.
- install CentOS 5 to a new LV and filesystem
- copy whatever's left of these files
- delete the old LV
- 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