Bug 133240 - recovery assertion tripped while bringing recovered node back up and mounting fs
Summary: recovery assertion tripped while bringing recovered node back up and mounting fs
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Cluster Suite
Classification: Retired
Component: gfs   
(Show other bugs)
Version: 4
Hardware: i686 Linux
medium
medium
Target Milestone: ---
Assignee: Ben Marzinski
QA Contact: GFS Bugs
URL:
Whiteboard:
Keywords:
Depends On: 142844 142853 142874
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-09-22 18:25 UTC by Corey Marthaler
Modified: 2010-01-12 02:58 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-11 22:10:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Corey Marthaler 2004-09-22 18:25:54 UTC
Description of problem:
revolver has having fun picking off nodes and then bringing them back
up once they had been recovered and on the 9th iteration it was trying
to bring morph-05 back up and it tripped this assert when attempting
to mount one of the filesystems:

GFS: Assertion failed on line 359 of file
/usr/src/cluster/gfs-kernel/src/gfs/recovery.c
GFS: assertion: "!error"
GFS: time = 1095875443
GFS: fsid=morph-cluster:corey0.4

Kernel panic: GFS: Record message above and reboot.

How reproducible:
Didn't try

Comment 1 Corey Marthaler 2004-10-29 19:36:20 UTC
Reproduced this one while running the same revolver senario. Again
this assert/panic happened while attempting to mount the first
filesystem on the recovered node.

Comment 2 Ken Preslan 2004-11-16 19:18:50 UTC
Reassign

Comment 3 michael conrad tadpol tilstra 2004-11-16 19:22:51 UTC
can you describe the setup? (nodes, fses, all that stuff.)

Comment 4 Corey Marthaler 2004-11-17 22:18:49 UTC
nodes: morph-01 - morph-05 
 
fses: 3 - 5 mounted on all nodes 
 
I/O being run: 
genesis genesis -n 500 -d 50 -p 3  
accordion accordion -p 3 accrdfile1 accrdfile2 accrdfile3 accrdfile4  
accrdfile5  
growfiles growfiles -i 0 -N 500 -n 3 -b  
iogen iogen -f buffered -m sequential -s read,write,readv,writev -t  
1b -T 100000b 100000b:rwbuflarge | doio -avk  
iogen iogen -f sync -m sequential -s read,write,readv,writev -t 1b  
-T 100000b 100000b:rwsynclarge | doio -avk  
 
Nodes run I/O, a subset gets shot, they get brought back up, repeat 
:) 

Comment 5 michael conrad tadpol tilstra 2004-11-18 18:30:12 UTC
 gulm or dlm?

Comment 6 Corey Marthaler 2004-11-18 19:03:55 UTC
dlm 

Comment 7 michael conrad tadpol tilstra 2004-12-22 21:17:05 UTC
I keep hitting these other three bugs trying to reproduce this one.

Comment 8 michael conrad tadpol tilstra 2005-08-03 13:47:34 UTC
do you still see this bug?

Comment 9 Kiersten (Kerri) Anderson 2005-10-11 21:45:41 UTC
Corey, have you seen this one?  If not, can we close it for now?

Comment 10 Corey Marthaler 2005-10-11 22:10:22 UTC
Have not seen this bug in almost a year, will reopen if seen again.


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