From owner-freebsd-hackers  Fri Mar  7 09:40:59 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id JAA02119
          for hackers-outgoing; Fri, 7 Mar 1997 09:40:59 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA02111
          for <freebsd-hackers@FreeBSD.ORG>; Fri, 7 Mar 1997 09:40:54 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id EAA23773; Sat, 8 Mar 1997 04:39:51 +1100
Date: Sat, 8 Mar 1997 04:39:51 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199703071739.EAA23773@godzilla.zeta.org.au>
To: freebsd-hackers@FreeBSD.ORG, jez@netcraft.co.uk
Subject: Re: Hard Link Count too small!
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>    Specifically, the following will create a directory with 32765
>subdirectories (not including `.', & `..') before bailing:
>
>    % mkdir tmp
>    % cd tmp
>    % perl -e '1 while (mkdir(++$c, 0755))'
>
>(you might want to mount the filesystem async beforehand :-)

I have some POSIX performance tests that do this several times.  They
take too long.  They take much too long if the filesystem is not async
mounted.

>    % ls -fa | wc -l 
>       32767

>So, could someone more knowledgeable about filesystem internals tell me why
>st_nlink is behaving like a signed short, and what I can do about it?

The limit is (bogusly) given by LINK_MAX in <sys/syslimits.h>.  This is
supposed to give the system-wide limit, but it is really only the ufs
limit.  You can probably safely increase it to slightly less than 65535.
Don't make it 65535, since ufs_rename() temporarily increases the link
count without checking the limit.

Bruce