Date: Tue, 11 Mar 1997 22:39:23 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, jez@netcraft.co.uk Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Hard Link Count too small! Message-ID: <199703111139.WAA10838@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
># 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703111139.WAA10838>