Date: Tue, 11 Mar 1997 10:55:29 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, jez@netcraft.co.uk, freebsd-hackers@FreeBSD.ORG Subject: Re: Hard Link Count too small! Message-ID: <199703111755.KAA25635@phaeton.artisoft.com> In-Reply-To: <199703111139.WAA10838@godzilla.zeta.org.au> from "Bruce Evans" at Mar 11, 97 10:39:23 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >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. Yeah; you'd get a compare warning on any reasonably modern compiler. Look at the NFS wire type for link count... The real question this generates in my mind is "why do you need so many links to solve this particular engineering problem?". I'd strongly advise using some other method to implement what you are trying to do. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703111755.KAA25635>