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 at slamb.org> >> Reply-To: CentOS mailing list <centos at centos.org> >> To: CentOS mailing list <centos at 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: >> >> 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/>