node3:/var/adm/ras # vi mmfs.log.latest
Mon Aug 9 21:13:21.867 2010: *** Assert exp(!"Assert on Structure Error")
in line 527 of file /build/ode/gpfs32/src/avs/fs/mmfs/ts/logger/Logger.C
Mon Aug 9 21:13:21.919 2010: *** Traceback:
Mon Aug 9 21:13:21.922 2010: 2:0x402D5D4E logAssertFailed + 0x14E
Mon Aug 9 21:13:21.929 2010: 21:0x2B614A0BCB3D clone + 0x6D
mmfsd: /build/ode/gpfs32/src/avs/fs/mmfs/ts/logger/Logger.C:527:
void logAssertFailed(unsigned int, char*, unsigned int, int, int,
unsigned int, char*, char*):
Assertion `!"Assert on Structure Error"' failed.
Mon Aug 9 21:13:21.928 2010: Signal 6 at location 0x2B614A02C5F5
in process 4961, link reg 0xFFFFFFFFFFFFFFFF.
Mon Aug 9 21:13:21.929 2010: rax 0x0000000000000000
rbx 0x00007FFF423FD170
结论：在 8 月 9 日 21 点 13 分左右，由于不合法的数据结构导致遇到断言错误。
6. 更改跟踪属性的设置：
由于目前的信息无法满足 GPFS 开发人员分析出该问题的缘由，所以根据开发人员的建议需要启动跟踪功能并设置一些特定的参数，具体内容如下：
增加跟踪文件的大小，使得它不会被很快的写满后被覆盖 : mmtracectl --set --trace-file-size=800M ；
在结构性错误发生时产生断言，由此可以自动捕获 GPFS 跟踪信息：mmchconfig assertOnStructureError=yes ；
每次在 GPFS 重启后，自动启动跟踪功能：TRACE_RECYCLE="global" ；
7. 启动跟踪功能：
在集群中任一节点上运行命令：mmtracectl --start
8. 重现问题并截获跟踪信息：
重新把系统运行起来直到 GPFS 再次遇到问题。此时在节点上执行 mmtrace stop 命令，这样就可以捕获到当问题发生时的详细的跟踪信息。
结束语
根据上面介绍的 GPFS 常见问题的诊断方法，我们可以在 GPFS 发生问题后进行相应检查，尽快查到问题所在恢复或者提供给相应技术人员更快解决，保证 GPFS 能够健康工作。