From owner-freebsd-fs@freebsd.org Mon Mar 7 08:21:15 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A099BAC320F for ; Mon, 7 Mar 2016 08:21:15 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from dg.fsn.hu (dg.fsn.hu [84.2.225.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dg.fsn.hu", Issuer "dg.fsn.hu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 628F595B; Mon, 7 Mar 2016 08:21:14 +0000 (UTC) (envelope-from bra@fsn.hu) Received: by dg.fsn.hu (Postfix, from userid 1003) id A59D820D0; Mon, 7 Mar 2016 09:21:05 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 12.2839] X-CRM114-CacheID: sfid-20160307_09210_3E1C7CED X-CRM114-Status: Good ( pR: 12.2839 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Mar 7 09:21:05 2016 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 56dd39f1568874377112279 X-DSPAM-Factors: 27, but, 0.01000, It's+possible, 0.01000, still+get, 0.01000, Also, 0.01000, Date*21+05, 0.01000, looks, 0.01000, looks, 0.01000, a+real, 0.01000, Received*online.co.hu+[195.228.243.99]), 0.01000, this+I've, 0.01000, Subject*at, 0.01000, >>+It, 0.01000, joy, 0.01000, linux, 0.01000, clear+why, 0.01000, >>+Correct, 0.01000, st_nlink, 0.01000, that+calls, 0.01000, FreeBSD+versions, 0.01000, Hartland, 0.01000, resolve, 0.01000, of, 0.01000, stat+st_nlink, 0.01000, From*"Nagy, Attila" , 0.01000, User-Agent*Mozilla/5.0, 0.01000, that+>, 0.01000, X-Spambayes-Classification: ham; 0.00 Received: from [IPv6:::1] (japan.t-online.co.hu [195.228.243.99]) by dg.fsn.hu (Postfix) with ESMTPSA id 59AB420CE; Mon, 7 Mar 2016 09:21:05 +0100 (CET) Subject: Re: zfs and st_nlink limit at 32767 To: Don Lewis , killing@multiplay.co.uk References: <201603052316.u25NGOaT079417@gw.catspoiler.org> Cc: freebsd-fs@freebsd.org From: "Nagy, Attila" Message-ID: <56DD39F1.8040302@fsn.hu> Date: Mon, 7 Mar 2016 09:21:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <201603052316.u25NGOaT079417@gw.catspoiler.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 08:21:15 -0000 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