The link count for a UFS/FFS inode is stored in a signed 16-bit integer. Thus the maximum link count has been 32767.
This limit has been recently hit by the poudriere build system when doing a ports build as it needs one directory per port and the number of ports recently passed 32767.
A long-term solution would be to use one of the spare 32-bit fields in the inode to store the link count. However, the UFS1 format does not have a spare and adding the spare in UFS2 would make it hard to make it compatible when running on older kernels that use the original link count field. So this patch uses the much simpler approach of changing the existing link count field from a signed 16-bit value to an unsigned 16-bit value. It has the fewest lines of code changes. The only thing that changes is the type in the dinode and inode structures and the definition of UFS_LINK_MAX. It has the added benefit that it works with both UFS1 and UFS2.
It allows easy backward compatibility. Indeed it is backward compatibility that is the primary reason to go with this approach. If a filesystem with the new organization is mounted on an older kernel, it still needs to work. Thus if we move the new link count to a new field, we still need to maintain the old link count as best as possible even when running on a kernel that knows about the larger link counts. And we would have to carry this overhead for the indefinite future.
If we have a new link-count field, we will have to add a new filesystem flag to indicate that we are running with larger link counts. We will also need to add of one of the new-feature flags to say that we have larger link counts. Older kernels clear the new-feature flags that they do not know about, so when a filesystem is used on an older kernel and then moved back to a newer one, the newer one will know that the new link counts have not been maintained and that it will be necessary to run a full fsck on the filesystem to correct the link counts before it can be mounted.
With this change, older kernels will generally work with the bigger counts. While it will not itself allow the link count to exceed 32767, it will have no problem working with inodes that have a link count greater than 32767. Since it tests that i_nlink <= UFS_LINK_MAX, counts that are bigger than 32767 will appear negative, so will still pass the test. Of course, if they ever drop below 32767, they will no longer be able to exceed 32767. The one issue is if the link count ever exceeds 65535 then it will wrap to zero and the older kernel will be none the wiser. But this corner case is likely to be very rare since these kernels and the applications running on them do not expect to be able to get link counts over 32767. And over time, the use of new filesystems on older kernels will become rarer and rarer.