From owner-freebsd-fs@freebsd.org  Sat Mar  5 23:16:31 2016
Return-Path: <owner-freebsd-fs@freebsd.org>
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 8E811A13A9B
 for <freebsd-fs@mailman.ysv.freebsd.org>; Sat,  5 Mar 2016 23:16:31 +0000 (UTC)
 (envelope-from truckman@FreeBSD.org)
Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified))
 by mx1.freebsd.org (Postfix) with ESMTPS id 77607AD5
 for <freebsd-fs@freebsd.org>; Sat,  5 Mar 2016 23:16:31 +0000 (UTC)
 (envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
 by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u25NGOaT079417;
 Sat, 5 Mar 2016 15:16:27 -0800 (PST)
 (envelope-from truckman@FreeBSD.org)
Message-Id: <201603052316.u25NGOaT079417@gw.catspoiler.org>
Date: Sat, 5 Mar 2016 15:16:23 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
Subject: Re: zfs and st_nlink limit at 32767
To: killing@multiplay.co.uk
cc: freebsd-fs@freebsd.org
In-Reply-To: <56DB4EA7.7050002@multiplay.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs/>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Mar 2016 23:16:31 -0000

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.