[Lustre-discuss] Lustre Mount Crashing

[Brian J. Murrell]

On Mon, 2008-06-02 at 11:35 -0400, Charles Taylor wrote:
> 
> Well, I figured someone would ask that.  :)    The last messages that  
> make it to syslog prior to the crash are....
> 
> Jun  2 10:29:54 hpcmds kernel: LDISKFS FS on md2, internal journal
> Jun  2 10:29:54 hpcmds kernel: LDISKFS-fs: recovery complete.
> Jun  2 10:29:54 hpcmds kernel: LDISKFS-fs: mounted filesystem with  
> ordered data mode.
> Jun  2 10:29:54 hpcmds kernel: kjournald starting.  Commit interval 5  
> seconds
> Jun  2 10:29:54 hpcmds kernel: LDISKFS FS on md2, internal journal
> Jun  2 10:29:54 hpcmds kernel: LDISKFS-fs: mounted filesystem with  
> ordered data mode.
> Jun  2 10:29:54 hpcmds kernel: Lustre: MGS MGS started
> Jun  2 10:29:54 hpcmds kernel: Lustre: Enabling user_xattr
> Jun  2 10:29:54 hpcmds kernel: Lustre: 4540:0:(mds_fs.c: 
> 446:mds_init_server_data()) RECOVERY: service ufhpc-MDT0000, 100  
> recoverable clients, last_transno 9412464331
> Jun  2 10:29:54 hpcmds kernel: Lustre: MDT ufhpc-MDT0000 now serving  
> dev (ufhpc-MDT0000/cac99db5-a66a-a6ac-4649-6ec8cc2dc0e7), but will be  
> in recovery until 100 clients reconnect, or if no clients reconnect  
> for 4:10; during that time new clients will not be allowed to connect.  
> Recovery progress can be monitored by watching /proc/fs/lustre/mds/ 
> ufhpc-MDT0000/recovery_status.
> Jun  2 10:29:55 hpcmds kernel: Lustre: 4540:0:(mds_lov.c: 
> 858:mds_notify()) MDS ufhpc-MDT0000: in recovery, not resetting  
> orphans on ufhpc-OST0004_UUID
> Jun  2 10:29:55 hpcmds kernel: Lustre: 4540:0:(mds_lov.c: 
> 858:mds_notify()) MDS ufhpc-MDT0000: in recovery, not resetting  
> orphans on ufhpc-OST0005_UUID

This is all perfectly normal.  Is there anything else or does this
amount to all that you are seeing?

> Note that all of the clients are powered off and the OSS's are  
> currently unmounted (though they appear to be fine).

Does anything bad happen when you bring up the OSSes?  Ideally, OSTs
should be brought up before the MDT but there is no requirement for
that.

> If it crashes

Do you have messages from a crash?

> a third time, and I suspect it will, I'll include some  
> of the stack trace.

Unless you are getting some kind of kernel panic, that stack trace
should be in the syslog.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20080602/4997330c/attachment.pgp>