* [linux-lvm] lvremove or vgextend: metadata too large for circular buffer
@ 2011-03-11 20:05 Andrew Gideon
2011-03-11 22:31 ` Andrew Gideon
2011-03-11 23:01 ` Ray Morris
0 siblings, 2 replies; 4+ messages in thread
From: Andrew Gideon @ 2011-03-11 20:05 UTC (permalink / raw)
To: linux-lvm
We're hitting the "metadata too large for circular buffer" problem. Last
time this occurred, I was able to clear out a little space by removing
some unused volumes, and then make more space by selective use of pvmove
to defragment. This worked well.
However, that time I didn't get the error from lvremove. This time, that
is occurring. So I don't seem to be able to make any space.
Once I execute lvremove on a volume, the "LV Status" becomes "NOT
available". The command 'lvdisplay -m' still shows the segments, however.
How can I resolve this? Trashing the entire VG is not something I can
afford.
I created new PVs with larger allocations of space for metadata, but I
cannot even add these to the VG. The vgextend command also fails with
"metadata too large for circular buffer".
- Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] lvremove or vgextend: metadata too large for circular buffer
2011-03-11 20:05 [linux-lvm] lvremove or vgextend: metadata too large for circular buffer Andrew Gideon
@ 2011-03-11 22:31 ` Andrew Gideon
2011-03-11 23:01 ` Ray Morris
1 sibling, 0 replies; 4+ messages in thread
From: Andrew Gideon @ 2011-03-11 22:31 UTC (permalink / raw)
To: linux-lvm
On Fri, 11 Mar 2011 20:05:12 +0000, Andrew Gideon wrote:
> However, that time I didn't get the error from lvremove. This time,
> that is occurring. So I don't seem to be able to make any space.
I've tried vgcfgrestore, but this too yields:
metadata too large for circular buffer
I ran some commands with -vvv. The output which seems to always
immediately precede the error is:
Doubling metadata output buffer to 131072
I also noticed that it appears to be looking at /dev/sdi and /dev/sdj.
These are two PVs I'd tried to add, but where vgextend also issued the
"too large..." error. These two PVs do not appear in 'vgdisplay -v'.
[root@backup2 backup]# /usr/sbin/lvremove -d -vvv -f /dev/jetarray004/i2-backup0 2>&1 | egrep 'sd[ij]'
Opened /dev/sdi RW O_DIRECT
/dev/sdi: block size is 4096 bytes
/dev/sdi: lvm2 label detected
lvmcache: /dev/sdi: now in VG #orphans_lvm2 (#orphans_lvm2)
Closed /dev/sdi
Opened /dev/sdj RW O_DIRECT
/dev/sdj: block size is 4096 bytes
/dev/sdj: lvm2 label detected
lvmcache: /dev/sdj: now in VG #orphans_lvm2 (#orphans_lvm2)
Closed /dev/sdj
[root@backup2 backup]#
Is there perhaps some "internal" VG (ie. #orphans_lvm2) that I'd be
able to successfully remove?
Thanks...
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] lvremove or vgextend: metadata too large for circular buffer
2011-03-11 20:05 [linux-lvm] lvremove or vgextend: metadata too large for circular buffer Andrew Gideon
2011-03-11 22:31 ` Andrew Gideon
@ 2011-03-11 23:01 ` Ray Morris
2011-03-12 3:48 ` Andrew Gideon
1 sibling, 1 reply; 4+ messages in thread
From: Ray Morris @ 2011-03-11 23:01 UTC (permalink / raw)
To: linux-lvm
> However, that time I didn't get the error from lvremove.
> This time, that is occurring. So I don't seem to be able to make any
> space.
> Once I execute lvremove on a volume, the "LV Status" becomes "NOT
> available". The command 'lvdisplay -m' still shows the segments,
> however.
> How can I resolve this? Trashing the entire VG is not something I
> can afford.
You may be able to manually do your removes on the output of
vgcfgbackup, then use vgcfgrestore. Be careful.
> I created new PVs with larger allocations of space for metadata, but
> I cannot even add these to the VG. The vgextend command also fails
> with "metadata too large for circular buffer"
What I did was to allocate MUCH more space on the new PVs,
make a new VG from them, then copy LVs from one of the old PVs.
Then recreate that PV with more metadata space, add it to the
new VG, etc. until all of the PVs are in the new VG, with far
more metadata space.
--
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 Fri, 11 Mar 2011 20:05:12 +0000 (UTC)
Andrew Gideon <ag2827189@tagmall.com> wrote:
> We're hitting the "metadata too large for circular buffer" problem.
> Last time this occurred, I was able to clear out a little space by
> removing some unused volumes, and then make more space by selective
> use of pvmove to defragment. This worked well.
>
> However, that time I didn't get the error from lvremove. This time,
> that is occurring. So I don't seem to be able to make any space.
>
> Once I execute lvremove on a volume, the "LV Status" becomes "NOT
> available". The command 'lvdisplay -m' still shows the segments,
> however.
>
> How can I resolve this? Trashing the entire VG is not something I
> can afford.
>
> I created new PVs with larger allocations of space for metadata, but
> I cannot even add these to the VG. The vgextend command also fails
> with "metadata too large for circular buffer".
>
> - Andrew
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] lvremove or vgextend: metadata too large for circular buffer
2011-03-11 23:01 ` Ray Morris
@ 2011-03-12 3:48 ` Andrew Gideon
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Gideon @ 2011-03-12 3:48 UTC (permalink / raw)
To: linux-lvm
On Fri, 11 Mar 2011 17:01:54 -0600, Ray Morris wrote:
> What I did was to allocate MUCH more space on the new PVs,
> make a new VG from them, then copy LVs from one of the old PVs. Then
> recreate that PV with more metadata space, add it to the new VG, etc.
> until all of the PVs are in the new VG, with far more metadata space.
Creating a new VG is my worst-case scenario, but that will be expensive
in terms of time - time during which I cannot do expansion of volumes.
It's a little frustrating.
How risky is the idea of editing a backup file and doing the restore? If
I screw it up, I can always do a re-restore of the proper data, no?
Thanks...
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-03-12 3:48 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-11 20:05 [linux-lvm] lvremove or vgextend: metadata too large for circular buffer Andrew Gideon
2011-03-11 22:31 ` Andrew Gideon
2011-03-11 23:01 ` Ray Morris
2011-03-12 3:48 ` Andrew Gideon
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).