du and ls Commands Take a Long Time on gfs2 filesystems

Environment

• Red Hat Enterprise Linux Server 5, 6, 7 (with the High Availability and Resilient Storage Add Ons)
• A Global Filesystem 2(GFS2)

Issue

• Running ls or du command on GFS2 filesystem appears to take a long time; "hang".

Resolution

Running ls with colors enabled, recursively, or when there are millions of files in a directory on a GFS2 filesystem has known to cause a performance issue.

For more information on GFS2 performance troubleshooting:

• Is my GFS2 slowdown a file system problem or a storage problem?
• My GFS2 filesystem is slow. How can I diagnose and make it faster?
• How to Improve GFS/GFS2 File System Performance and Prevent Processes from Hanging
• GFS2 Best Practices

Root Cause

In situations where a GFS file system is slow to respond, the first response of many users is to run ls in order to determine the problem. If the --color option is enabled for the ls command, then ls must run a stat() against every entry, which creates additional lock requests and can create contention for those files with other processes.
This might exacerbate the problem and cause slower response times for processes accessing that filesystem. Our recommendation is to disable ls with colors enabled.

In addition, running ls recursively or where there are millions of files in a directory can cause a performance issue. It is best to only use ls sparingly.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.