From owner-freebsd-hackers  Tue Mar 11 03:40:50 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id DAA19533
          for hackers-outgoing; Tue, 11 Mar 1997 03:40:50 -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 DAA19523
          for <freebsd-hackers@FreeBSD.ORG>; Tue, 11 Mar 1997 03:40:47 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id WAA10838; Tue, 11 Mar 1997 22:39:23 +1100
Date: Tue, 11 Mar 1997 22:39:23 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199703111139.WAA10838@godzilla.zeta.org.au>
To: bde@zeta.org.au, jez@netcraft.co.uk
Subject: Re: Hard Link Count too small!
Cc: freebsd-hackers@FreeBSD.ORG
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

># 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.

>Thanks for this, but it doesn't quite work!  I bumped up the limit to 65530,
>...
>Looking at sys/ufs/ufs/ufs_vnops.c, LINK_MAX is compared against ip->i_nlink
>(ufs_link() and ufs_rename()), and further digging shows that i_nlink is a
>#define for i_din.di_nlink (sys/ufs/ufs/inode.h) and di_nlink is a signed
>short (sys/ufs/ufs/dinode.h)!

Urk.

>So, what are the implications of changing di_nlink to unsigned short
>(or should that be u_int16_t?)?

I guess it would just work (but I've been wrong before :-) except
you would have to worry more about how vanilla BSDs would handle it.
If everyone used unsigned types with a limit of 32767, then larger values
on the disk would at worst cause fsck errors and at best cause only link()
failures, but negative di_nlink values would pass the `ip->i_nlink <= 0'
test in ufs_inactive() and bad things would happen.  ip->i_nlink is cast
to (nlink_t) for all other related tests in ufs.  Casting is worse than
using the wrong on-disk type.  It masks problems now, and if anyone changes
nlink_t to be larger than the on-disk type, then the cast will become a
no-op.

fsck actually doesn't check LINK_MAX but it does check dp->d_nlink <= 0.

Bruce