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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
