1. Support
  2. Knowledge base
  3. 100011372

vx_maxlink tunable; mkdir too many links

Article: 100011372
Last Published: 2019-04-03
Ratings: 0 0
Product(s): InfoScale & Storage Foundation

Problem

Maximum number of subdirectories, in a single directory, is limited to 32767, or the value of vx_maxlink tunable.

Error Message

mkdir too many links.

Cause

There is a limit to the number of directories that can be created in one directory. For the VXFS filesystem this limit is controlled by a tunable vx_maxlink, in most cases the default is 32,767.  

A potential workaround is to use more “depth” in your subdirectories.  
For Example:
/export can hold 32,767 directories, each of those directories can also hold 32,767, and so on. So instead of trying to put 32,767+ directories directly in /export use more depth like /export/<the_date> or whatever makes more sense for the individual situation.
Before making any changes, it’s highly recommended that you research the maximum value for your current OS. Some OS’s may not be able to address over 32,767 subdirectories even if the tunable is available for that OS. Setting this tunable higher than what is supported by your OS can have unpredictable and potentially devastating effects.


Solution

Solution: (Solaris)

The VxFS vx_maxlink tunable determines the number of sub-directories that can
be created under a directory.
 
A VxFS file system obtains the value of vx_maxlink from the system configuration
file /etc/system. By default, vx_maxlink is 32K. To change the computed value
of vx_maxlink, you can add an entry to the system configuration file.
 
For example:
set vxfs:vx_maxlink = 65534
 
sets vx_maxlink to the maximum number of sub-directories. Valid values are 1
to 65534 (FFFE hexadecimal).
 
Changes to vx_maxlink take effect after rebooting.
 
Solution: (RHEL 5.X)
See:
 
Solution (RHEL 6.X and 7.X)
See:
https://www.veritas.com/support/en_US/article.100033962
 
Solution (AIX)
See:

Applies To

VXFS filesystem on Solaris, RHEL and AIX. Probably also on SUSE and HP-UX as well. 

Note for CFS filesystems
The situation gets a little more complicated for CFS filesystems. Basically the master node for the filesystem needs to be rebooted to get the change to take effect. However, once you attempt to reboot the master node for the CFS filesystem, the cluster will elect a new master while the old master reboots. Thus in order to get this to take effect for a CFS filesystem, the above changes will have to be made on each node and each node needs to be rebooted.   It’s up to the customer if they want to do one at a time, or all at once.

 
Note: While it might be possible to make these changes to one node, reboot it, then force it to be the master. It’s unclear what will happen if that node crashes or for some other reason gives up being the master node for the filesystem to another node that does not have these modifications made. It will most likely lead to data corruption in the directory that contains over 32,767 subdirectories. Thus it’s highly recommended to make the changes cluster wide at the same time.
 

Was this content helpful?

Article Languages