Date: Sat, 5 Mar 2016 15:16:23 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: killing@multiplay.co.uk Cc: freebsd-fs@freebsd.org Subject: Re: zfs and st_nlink limit at 32767 Message-ID: <201603052316.u25NGOaT079417@gw.catspoiler.org> In-Reply-To: <56DB4EA7.7050002@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 Mar, Steven Hartland wrote: > Correct stat st_nlink is a nlink_t which is defined as uint16_t, its not > clear why its clamping at what looks like int16_t max. > > It looks like the kernel version in nstat is a uint32_t so internally it > should be correct. > > You may have some joy changing it to uint32_t but is likely everything > will rebuilding and even then there may be some edge cases which break > one that sticks out is linux compat support which doesn't use nlink_t. Yeah, changing it would change the stat() ABI, so you would have to recompile everything that calls stat(). Also the syscall would have to be versioned so that executables built on previous FreeBSD versions would still get the old version of struct stat. Something else to look out for is archive formats. It's possible that nlinks is embedded in them. Breaking the ability to read your old backup tapes would be a real bummer.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201603052316.u25NGOaT079417>