[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gfs-bugs
Subject:    [gfs-bugs] [Bug 310] New - apc_ms STOMITH fires too late
From:       bugzilla-daemon () sistina ! com
Date:       2001-10-17 0:40:27
[Download RAW message or body]

http://bugzilla.sistina.com/show_bug.cgi?id=310

*** shadow/310	Tue Oct 16 19:40:27 2001
--- shadow/310.tmp.12959	Tue Oct 16 19:40:27 2001
***************
*** 0 ****
--- 1,30 ----
+ Bug#: 310
+ Product: GFS
+ Version: 4.2
+ Platform: 
+ OS/Version: All
+ Status: NEW   
+ Resolution: 
+ Severity: normal
+ Priority: P4
+ Component: STOMITH
+ AssignedTo: gfs-bugs@sistina.com                            
+ ReportedBy: rlatham@plogic.com               
+ URL: 
+ Summary: apc_ms STOMITH fires too late
+ 
+ . fibre channel hardware with DMEP support
+ . apc master switches
+ . two nodes ( minas1 and minas2 )
+ . GFS configured to use the apc_ms STOMITH method
+ 
+ Steps to reproduce
+ . minas1 and minas2 mount /gfs0 and both do stuff like unpacking a large tarbal
+ . bring down the interface on minas2 ( i'm logged in over a serial console)
+ . wait many many minutes.   far far longer than "timeout: 30"
+ . manually reboot minas2 ( /sbin/shutdown -r now )
+ . shortly into minas2's boot process, minas1 *finally* realises that minas2 is dead and STOMITHs it.  
+ . minas2 reboots again and comes up like he should
+ 
+ 
+ Who's fault is the long long delay in realizing that minas2 has gone dead?

Read the GFS HOWTO http://www.sistina.com/gfs/Pages/howto.html
gfs-bugs mailing list
gfs-bugs@sistina.com
http://lists.sistina.com/mailman/listinfo/gfs-bugs
Read the GFS Howto:  http://www.sistina.com/gfs/Pages/howto.html

[prev in list] [next in list] [prev in thread] [next in thread]