From owner-freebsd-fs@FreeBSD.ORG Fri Nov 21 16:14:46 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9DCB3CE for ; Fri, 21 Nov 2014 16:14:46 +0000 (UTC) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB05E61B for ; Fri, 21 Nov 2014 16:14:46 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id sALGEjRb082219; Fri, 21 Nov 2014 08:14:45 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201411211614.sALGEjRb082219@chez.mckusick.com> To: Konstantin Belousov Subject: Re: RFC: patch to make d_fileno 64bits In-reply-to: <20141121155754.GN17068@kib.kiev.ua> Date: Fri, 21 Nov 2014 08:14:45 -0800 From: Kirk McKusick Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 16:14:46 -0000 > Date: Fri, 21 Nov 2014 17:57:54 +0200 > From: Konstantin Belousov > To: Rick Macklem > Subject: Re: RFC: patch to make d_fileno 64bits > > I do not think we need to have in-kernel compatibility shims. > The work, big but relatively trivial, is to convert filesystems to > use the new ino_t, even if the on-disk structures still use 32bit > inode number. > > Really problematic part of this change is the usermode ABI breakage. > The struct dirent is only the start of the whole issue. ino_t is > embedded into more structures which are part of the contract, e.g. > struct stat. We have to provide new syscalls which accept or return > the affected structures. > > And then, there are libraries which embed ino_t into their ABI. > Immediate example is fts(3) in libc. Look at the FTSENT.fts_ino. Even > after the base system is fixed by properly providing the compat shims > and symbol versions for the affected libraries, we get the same problem > with the binaries not from base. > > Summary of the issue with ino_t is that it is not too hard to fix the > kernel, comparing with the ABI issues which must be solved in usermode. You are quite right that this is a big and complex process. It was first attempted as a Google Summer of Code project which was later (in August 2011) integrated in projects/ino64. The hurdle for getting it in was too high and it has since languished. We discussed the need to get this done at the MeetBSD developer summit and I agreed to take a fresh look to see if we could pull it off in time for FreeBSD-11. I have started looking at resurrecting the work done in projects/ino64 and will work with Rick to come up with a proposal. As you note, getting a kernel working with backward compatibility is straight-forward. If you have ideas on how to handle the usermode ABI issues, they would be most appreciated. Kirk McKusick