Bug 146696 - possible metadata coruption trying to active VG
possible metadata coruption trying to active VG
Status: CLOSED WORKSFORME
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: lvm2-cluster (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Alasdair Kergon
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-31 15:48 EST by Corey Marthaler
Modified: 2010-01-11 23:02 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-01 11:24:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Corey Marthaler 2005-01-31 15:48:55 EST
Description of problem:
this may be related to bz146056 but unlike bz146056, these appear to
be real errors and afterwards, the clvmd cmds hang indefinately.

I've reproduced this a few times now during the second recovery
attempt.  The node being brought back up sees theses errors during the
vg activation:
  Huge memory allocation (size 1124073490) rejected - metadata corruption?
  Huge memory allocation (size 1916097632) rejected - metadata corruption?
  Huge memory allocation (size 1332770115) rejected - metadata corruption?
  Huge memory allocation (size 959853662) rejected - metadata corruption?

and then afterwards, other clvmd cmds like this vgdisplay hang:
.
.
.
stat64("/dev/hda1", {st_mode=S_IFBLK|0660, st_rdev=makedev(3, 1),
...}) = 0
stat64("/dev/sda1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 1),
...}) = 0
stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17),
...}) = 0
stat64("/dev/sdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 33),
...}) = 0
stat64("/dev/sdd1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 49),
...}) = 0
stat64("/dev/hda2", {st_mode=S_IFBLK|0660, st_rdev=makedev(3, 2),
...}) = 0
stat64("/dev/hda3", {st_mode=S_IFBLK|0660, st_rdev=makedev(3, 3),
...}) = 0
time(NULL)                              = 1107203815
getpid()                                = 3922
stat64("/etc/lvm/archive", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
stat64("/etc/lvm/backup", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
stat64("/etc/lvm/lvm.conf", {st_mode=S_IFREG|0644, st_size=10126,
...}) = 0
open("/usr/lib/liblvm2clusterlock.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\7\0\000"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=7932, ...}) = 0
old_mmap(NULL, 10500, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x1ba000
old_mmap(0x1bc000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x1000) = 0x1bc000
close(3)                                = 0
socket(PF_UNIX, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_UNIX, path=@clvmd}, 110

Also, the devices never show up:
[root@morph-02 root]# ls /dev/mapper/gfs-gfs1
/dev/mapper/gfs-gfs1
[root@morph-02 root]# mount -t gfs /dev/mapper/gfs-gfs1 /mnt/gfs1
mount: /dev/mapper/gfs-gfs1 is not a valid block device


Version-Release number of selected component (if applicable):
[root@morph-03 root]# clvmd -V
Cluster LVM daemon version: 2.01.02 (2005-01-21)
Protocol version:           0.2.1


How reproducible:
Sometimes
Comment 1 Kiersten (Kerri) Anderson 2005-02-01 10:32:48 EST
Adding to release blocker list
Comment 2 Christine Caulfield 2005-02-01 11:15:58 EST
I can't reproduce this, the LVM errors at the top of the bug report
look quite nasty though - Alasdair ??
Comment 3 Alasdair Kergon 2005-02-01 12:13:58 EST
Not enough info, but the usual cause of those memory errors is corrupt lvm1
metadata.  Need -vvvv (or lvm2 logfile) output from the command giving the
memory error, or a dump of the data at the start of the device which it read
causing it.
Comment 4 Kiersten (Kerri) Anderson 2005-02-23 12:40:26 EST
Removing from blocker list.  If it is recreatable, then will get back on the
list at that time.
Comment 5 Corey Marthaler 2005-03-14 16:50:26 EST
Added more discriptive summary.
This issue was only seen that one time.
Comment 6 Alasdair Kergon 2006-02-01 11:24:42 EST
A year has passed without seeing this again, so closing it for now.

Note You need to log in before you can comment on or make changes to this bug.