On Jun 14, 2008 08:06 -0400, Charles Taylor wrote: >>> 1. A ton of lustre-log.M.N files get dumped into /tmp in a short >>> period of time. Most of them appear to be full of garbage and >>> unprintable characters rather than thread stack traces. Many of them >>> are also zero length. >> >> The lustre-log files are not stack traces. They are dumped lustre debug >> logs. > > Got it.
Just to mention - you can decode these files using the command: lctl df <logfile> <textfile> >>> We are open to suggestion and wondering if we should update the MDSs >>> to 1.6.5. Can we do that safely without also upgrading the clients >>> and OSTs? >> >> In general the MDS and OSS nodes should run the same level of software, >> as that is what we test, but there isn't a hard requirement for it. > > Would it be reasonable then, to upgrade the MDSs and OSSs but leave the > clients at 1.6.4.2 or is that asking for trouble. I think this comes up a > lot and I'm pretty sure people have said they do it successfully. I'm > just wondering if it is a *design* goal that is architected in or just > something that happens to work most of the time. The Lustre upgrade process is always planned to allow 1.X.Y to work for all 'Y' values, and between 1.X.Y_latest and 1.X_next.Z. We test these combinations for Lustre releases, for both interoperability and upgrade. In the vast majority of cases 1.X_next will work with any 1.X release, but we can't test all combinations so we don't make such claims. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. _______________________________________________ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss