From: Ray Morris <support@bettercgi.com>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] How to fix missmatch between VG-size and LV-size?
Date: Tue, 29 Mar 2011 17:26:59 -0500 [thread overview]
Message-ID: <20110329172659.4a921f53@bettercgi.com> (raw)
In-Reply-To: <CE3415B4EB40445F8F294A52BC905070@caramon>
7> Run "resize2fs /dev/vgftp/lvftp"
> resize2fs 1.41.10 (10-Feb-2009)
> Resizing the filesystem on /dev/vgftp/lvftp to 1115800576 (4k)
> blocks
> Resizing the filesystem on /dev/vgftp/lvftp to 1115800576 (4k)
> blocks
8> Here it all hangs. I cant do anything with the filesystem or LVM.
8> every
You can expect resize2fs to take a couple of hours on a 4 TB
filesystem, so the "crash" may well be nothing but impatience.
> If i do a lvreduce i fear something will break.
> Is it better to do a e2fsck now?
The problem that we know about is that the resize2fs was
interrupted. Reports defer in the level in danger in that,
but definitely we want to get the filesystem consistent and
small enough before we pull the block device out from underneath
it. So yes, you need a passing e2fsck before an lvreduce at
this points.
The safest thing to do would be make a copy of at least the LV,
if not both PVs, so you can get back to where you are if needed.
That's almost always the first best step for any kind of data
recovery type of effort.
Once you have a copy or have checked that your backups are Ok,
you can proceed with e2fsck. After e2fsck passes, you can try
to pvmove the extents off of the new drive, if you wish. If
the LV won't fit on the old drive, you'll need to resize2fs
and lvreduce to make it fit. It can be hard to know just how
big to make the LV for a given FS size, due to filesystem overhead
and such. A safe way to do it would be to resize2fs as small
as possible first. That'll probably give you at least 10%-20%
of margin between the size of the FS and the size of the PV.
Then resize the LV to match the PV. Once the LV is at it's final
size, resize2fs to max.
Check that your LV is in fact the same size as it was
before your lvextend and the output of "history". It sounds
like either a) you didn't run exactly the commands that you
are reporting or b) the LV is in fact larger than it used
to be. If you ran lvextend to increase the size of the LV
and did not reduce it after, a crash during resize2fs isn't
going to shrink it automagically. Also, if it were at the
old size, it probably wouldn't be on both PVs. Therefore,
the LV probably actually is 400GB larger than it used to be.
--
Ray Morris
support@bettercgi.com
Strongbox - The next generation in site security:
http://www.bettercgi.com/strongbox/
Throttlebox - Intelligent Bandwidth Control
http://www.bettercgi.com/throttlebox/
Strongbox / Throttlebox affiliate program:
http://www.bettercgi.com/affiliates/user/register.php
On Tue, 29 Mar 2011 23:56:03 +0200
"Fredrik Skog" <fredrik.skog@rodang.se> wrote:
> But since lvdisplay says the volume is 4.16TiB and pvdisplay says
> 5.59TiB something is wrong? Or am I missing something?
next prev parent reply other threads:[~2011-03-29 22:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-29 15:21 [linux-lvm] How to fix missmatch between VG-size and LV-size? Fredrik Skog
2011-03-29 17:44 ` Ray Morris
2011-03-29 21:56 ` Fredrik Skog
2011-03-29 22:14 ` Stuart D. Gathman
2011-03-29 23:42 ` Fredrik Skog
2011-03-30 0:27 ` Fredrik Skog
2011-03-30 15:04 ` Ray Morris
2011-03-31 15:06 ` Fredrik Skog
2011-03-31 15:24 ` Ron Johnson
2011-03-31 17:39 ` Stuart D. Gathman
2011-03-31 19:19 ` Georges Giralt
2011-04-01 1:08 ` Fredrik Skog
2011-03-29 22:26 ` Ray Morris [this message]
2011-03-30 0:05 ` Fredrik Skog
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110329172659.4a921f53@bettercgi.com \
--to=support@bettercgi.com \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).