GET_FILESYSTEM execution takes several minutes on NFS shares

Products

• CA Automic Workload Automation - Automation Engine

Issue/Introduction

Symptoms

When using the Automic script function GET_FILESYSTEM (specifically with PATH_SPACE_USED or PATH_FILE_COUNT) on Linux agents to check files located on NFS-mounted shares, the script execution experiences severe delays.

• Activation reports show the function taking 10 minutes or longer to complete.
• The issue often appears intermittent or restricted to specific large NFS shares.
• Standard Linux commands like stat or ls on the same file from the agent's CLI return immediately.

Environment

Product: Automic Workload Automation

Component: Automation Engine / Linux Agent

Version: v21, v24.x, v26.x

Storage: NFS-mounted file systems or vSAN NFS shares

Cause

The GET_FILESYSTEM script function defaults to Include_Subdirectories=Y. When this parameter is active, the agent performs a recursive search across the directory tree to collect metadata.

On NFS shares, this triggers a high volume of READDIR and GETATTR calls. If the directory structure is deep or contains a large number of files, network latency and NFS metadata processing bottlenecks (common in vSAN 8.x and other NFS protocols) cause the function to hang while it traverses the file system.

 

Resolution

Explicitly disable the recursive search parameter in the GET_FILESYSTEM call if you are targeting a specific file or a single directory level.

Updated Script Example

Add the "N" flag to the Include_Subdirectories parameter (the 7th parameter of the function):

! Original slow call (defaults to "Y")
:SET &SIZE# = GET_FILESYSTEM(&HOST#, '&PATH#', PATH_SPACE_USED, 'Bytes', , &LOGIN#)



! Optimized call (explicitly set to "N")
:SET &SIZE# = GET_FILESYSTEM(&HOST#, '&PATH#', PATH_SPACE_USED, 'Bytes', "N", &LOGIN#)