[gpfsug-discuss] mmfsck runs very slowly on a small filesystem

[Eric Sperley]

Mengxing,

It is nice meeting you.

I have seen a situation where the amount of RAM on a node can affect mmfsck
times. Do all the nodes have the same amount of RAM, or does the slow
running node have less RAM?


Best Regards, Eric



                                                                                 
                                                                                 
                                                                                 
                                               Eric Sperley                      
                                                                                 
                                               SDI Architect                     
                                                                                 
     "Carpe Diem"                              IBM Systems                       
                                                                                 
                                               esperle at us.ibm.com                
                                                                                 
                                               +15033088721                      
                                                                                 







From:	Mengxing Cheng <mxcheng at uchicago.edu>
To:	"gpfsug-discuss at spectrumscale.org"
            <gpfsug-discuss at spectrumscale.org>
Date:	03/09/2017 11:24 AM
Subject:	[gpfsug-discuss] mmfsck runs very slowly on a small filesystem
Sent by:	gpfsug-discuss-bounces at spectrumscale.org



Dear all,

My name is Mengxing Cheng and I am a HPC system administrator at the
University of Chicago. We have a GSS26 running gss2.5.10.3-3b and
gpfs-4.2.0.3.

Recently, we run mmfsck on a relatively small filesystem with 14TB block
and 73863102 inodes but it was unusually slow so as to not be able to
finish in 48 hours. In contrast, mmfsck run on a filesystem with the same
size and inodes but sitting on a traditional IBM DS3512 storage  took only
2 hours to complete.

In particular, the mmfsck run in parallel using 3 nodes within the GSS
storage cluster, we notice that one gss storage server scans inodes much
slower than the other gss storage server and the quorum service node.

Has anyone experience the same mmfsck performance issue?
Could anyone make recommendation to troubleshoot and improve mmfsck
performance?

Thank you!


Mengxing


---
Mengxing Cheng, Ph.D.
HPC System Administrator
Research Computing Center
The University of Chicago

5607 S. Drexel Ave.
Chicago, IL 60637
email:    mxcheng at uchicago.edu
phone:  (773) 702-4070

_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170309/72014f48/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1C803747.gif
Type: image/gif
Size: 481 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170309/72014f48/attachment-0008.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170309/72014f48/attachment-0009.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1C166252.gif
Type: image/gif
Size: 2322 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170309/72014f48/attachment-0010.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170309/72014f48/attachment-0011.gif>