Date: Mon, 7 Mar 2016 09:21:05 +0100 From: "Nagy, Attila" <bra@fsn.hu> To: Don Lewis <truckman@FreeBSD.org>, killing@multiplay.co.uk Cc: freebsd-fs@freebsd.org Subject: Re: zfs and st_nlink limit at 32767 Message-ID: <56DD39F1.8040302@fsn.hu> In-Reply-To: <201603052316.u25NGOaT079417@gw.catspoiler.org> References: <201603052316.u25NGOaT079417@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On 03/06/16 00:16, Don Lewis wrote: > 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. In the hope that somebody will eventually resolve this, I've filed a bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207763
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56DD39F1.8040302>