From owner-freebsd-fs@freebsd.org Mon May 15 22:01:37 2017 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 4354FD6E86F for ; Mon, 15 May 2017 22:01:37 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ECB3A1334 for ; Mon, 15 May 2017 22:01:36 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x22c.google.com with SMTP id a72so111608817qkj.2 for ; Mon, 15 May 2017 15:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=PKAVcDKkyQx9ntzPsSXWZAMOkhBQFpfaAyy7s7oIdSM=; b=L1mYS0CsICQjW9gkwvmDteLkabuDMQEJz4f8spMVSEIyVT1ZB4iKxmGtaGW339WWk4 kEdl9UYpqbGCoXUHmJgSZXRFCc8uIprGBa9K1L6kltJ4g0pnn+gpMh9pQmu/GyKNn3oC fAu2lEkNMjeFWQOXCbBwt3zd3+BOsK9DGUrc6sIubuzSx61Y8tbyWIuU6TwfPcmLAm21 ydjOlIUrVF/BQ5kOuVBQHvfYe+RORgi1I5TO5qKFxREFglU8np2n/weO9mCHmTMteKWu 3IlM/ddgP3urinElSausp2kHmVDAnAuURPF+XxJYxVszsMaBYK/3w68BBkl5M1dwLVof FGTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PKAVcDKkyQx9ntzPsSXWZAMOkhBQFpfaAyy7s7oIdSM=; b=HZ4lKQtt9xcr/ARZyyeA5uoOVhwxD+rMmYqcDX8UbCpDpipvFEAaLLmyDNsKjQjQdY K95sYfZpbb2MkVFciloG4L0PYUMdtt4KHIDt2SBIs4mhyR/T/EKGq4DeO2LUYV4MUdQM r77oYFiElJ3cpOY/WO3d4vm8sP4dVKu6H7Cllm4jweN7l8n7IaNFxJY1oEJs4blHgI+Y mi47qtTZ7lWF5h1rsGjxAtjC3PuSRv2s6CO/8+HtdUA7Spo8jbG5gMOoQkfjSPLEz458 35thghY46PZeh14700wNwFIsgVWclGU16PKcP2s4u8+3IjvniCWYXty1js+hpQrahkiL jOEQ== X-Gm-Message-State: AODbwcC1scDcPcF6P4P35suThzo2IjZD45pBvK5RMMgINsNTaNtt8eeZ yi4Zzz8Ef2PraPQT X-Received: by 10.233.237.72 with SMTP id c69mr8068210qkg.201.1494885695903; Mon, 15 May 2017 15:01:35 -0700 (PDT) Received: from mutt-hbsd ([63.88.83.66]) by smtp.gmail.com with ESMTPSA id t35sm9400920qta.62.2017.05.15.15.01.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 May 2017 15:01:35 -0700 (PDT) Date: Mon, 15 May 2017 18:01:33 -0400 From: Shawn Webb To: Konstantin Belousov Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, freebsd-ports@freebsd.org, emaste@freebsd.org, Kirk McKusick Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing Message-ID: <20170515220133.hxp6x2zvlfdilsiq@mutt-hbsd> References: <20170420194314.GI1788@kib.kiev.ua> <20170515194145.tx2mp6gxjxbcpbng@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="h36hr3agvrxrlxsc" Content-Disposition: inline In-Reply-To: <20170515194145.tx2mp6gxjxbcpbng@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170306 (1.8.0) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 22:01:37 -0000 --h36hr3agvrxrlxsc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 15, 2017 at 03:41:45PM -0400, Shawn Webb wrote: > On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote: > > Inodes are data structures corresponding to objects in a file system, > > such as files and directories. FreeBSD has historically used 32-bit > > values to identify inodes, which limits file systems to somewhat under > > 2^32 objects. Many modern file systems internally use 64-bit identifiers > > and FreeBSD needs to follow suit to properly and fully support these > > file systems. > >=20 > > The 64-bit inode project, also known as ino64, started life many years > > ago as a project by Gleb Kurtsou (gleb@). After that time several > > people have had a hand in updating it and addressing regressions, after > > mckusick@ picked up and updated the patch, and acted as a flag-waver. > >=20 > > Sponsored by the FreeBSD Foundation I have spent a significant effort > > on outstanding issues and integration -- fixing compat32 ABI, NFS and > > ZFS, addressing ABI compat issues and investigating and fixing ports > > failures. rmacklem@ provided feedback on NFS changes, emaste@ and > > jhb@ provided feedback and review on the ABI transition support. pho@ > > performed extensive testing and identified a number of issues that > > have now been fixed. kris@ performed an initial ports investigation > > followed by an exp-run by antoine@. emaste@ helped with organization > > of the process. > >=20 > > This note explains how to perform useful testing of the ino64 branch, > > beyond typical smoke tests. > >=20 > > 1. Overview. > >=20 > > The ino64 branch extends the basic system types ino_t and dev_t from > > 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit. The struct dirent > > layout is modified due to the larger size of ino_t, and also gains a > > d_off (directory offset) member. As ino64 implies an ABI change anyway > > the struct statfs f_mntfromname[] and f_mntonname[] array length > > MNAMELEN is increased from 88 to 1024, to allow for longer mount path > > names. > >=20 > > ABI breakage is mitigated by providing compatibility using versioned > > symbols, ingenious use of the existing padding in structures, and by > > employing other tricks. Unfortunately, not everything can be fixed, > > especially outside the base system. For instance, third-party APIs > > which pass struct stat around are broken in backward and forward- > > incompatible way. > >=20 > > 2. Motivation. > >=20 > > The main risk of the ino64 change is the uncontrolled ABI breakage. > > Due to expansion of the basic types dev_t, ino_t and struct dirent, > > the impact is not limited to one part of the system, but affects: > > - kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo > > and more) > > - libc interface (mostly related to the readdir(3), FTS(3)) > > - collateral damage in other libraries that happens to use changed types > > in the interfaces. See, for instance, libprocstat, for which compat > > was provided using symbol versioning, and libutil, which shlib version > > was bumped. > >=20 > > 3. Quirks. > >=20 > > We handled kinfo sysctl MIBs, but other MIBs which report structures > > depended on the changed type, are not handled in general. It was > > considered that the breakage is either in the management interfaces, > > where we usually allow ABI slip, or is not important. > >=20 > > Struct xvnode changed layout, no compat shims are provided. > >=20 > > For struct xtty, dev_t tty device member was reduced to uint32_t. It > > was decided that keeping ABI compat in this case is more useful than > > reporting 64bit dev_t, for the sake of pstat. > >=20 > > 4. Testing procedure. > >=20 > > The ino64 project can be tested by cloning the project branch from > > GitHub or by applying the patch > at URL | attached> to a working tree. The authorative source is the > > GitHub, I do not promise to update the review for each update. > >=20 > > To clone from GitHub: > > % git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git i= no64 > >=20 > > To fetch the patch from Phabricator: > > - Visit https://reviews.freebsd.org/D10439 > > - Click "Download Raw Diff" at the upper right of the page > >=20 > > Or > > % arc patch D10439 > >=20 > > After that, in the checkout directory do > > % (cd sys/kern && touch syscalls.master && make sysent) > > % (cd sys/compat/freebsd32 && touch syscalls.master && make sysent) > > If you use custom kernel configuration, ensure that > > options COMPAT_FREEBSD11 > > is included into the config. Then build world and kernel in the > > usual way, install kernel, reboot, install new world. Do not make > > shortcuts in the update procedure. >=20 > Hey Kostik, >=20 > On my HardenedBSD system, world compiled fine with the patch, but the > kernel didn't compile. I've uploaded the log to: >=20 > https://hardenedbsd.org/~shawn/2017-05-15_ino64-r01.log >=20 > This was from importing the patch from Phabricator into > hardened/current/master in HardenedBSD. Update: I missed a step. Kernel and world built fine. It seems the patch is working fine for me in a limited test. I'll do a more involved test tomorrow. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --h36hr3agvrxrlxsc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlkaJToACgkQaoRlj1JF bu5Q8A//UjtI66Dxx4vNYviBvrqUXZf+cpY+FsGWUnCiIsNYpmZoLmkNjGqyW5PF OBlq7wpC6R5gUlKLsaV4/7Qe6biGKv8JIr1CujjQKX/gGfHZ7ILrVWyQE6uHFM/a YvFQ3GX4j45fOZGx5Fh7IjzfUaCeBMj0+apdbUyeUZr8h3uqtVy6qY0n0g4i5X0L P6bS57cNXWhSin2lXA98/b89p2DCOOH6TjqvAjB9gbwFs5mzujkS7KgZruaOFWnT csnfgoaqqdzLQDLXrLqURnL50rAE6ALvzUb/+C+TYnNnXTMCzbvRNOJOqhuZ2WiH USbn0IH9bB87cIWTaeYce171dTbBuAAyoAiGSaYEAMhJC+QRirl4M6L1VrJdFLVd VKGkWrtXGJ28u8UlEB+yOp9e/t11DnvVLuU6kqiGlQFlPPP9cu2Kmqcq7bcKwPE1 3Rl4jJjbCiD7LPMKgs3u3IEoSiM90yFUsXf7UByyGpE2ViGMqUH7i+pPQxFYTWQ1 sKiimmCvOxAz0h93lFS3CC5Vti3Gc+rY2tpuCwbyuctBGbJ5VzzVwjinKgOVHVj3 4Mb/1EEId99LWRIt7OVvvmuzs4lWn9MZnK0G/Trpa0lJmHpSFiGN9lZ8Xk7j1B8m DqL9fh8ZCnGhtWiicwWcSOgYpHOF0WpbvXEuuEOpued6GSDezXc= =SIYn -----END PGP SIGNATURE----- --h36hr3agvrxrlxsc--