Date: Mon, 15 May 2017 15:41:45 -0400 From: Shawn Webb <shawn.webb@hardenedbsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, freebsd-ports@freebsd.org, emaste@freebsd.org, Kirk McKusick <mckusick@mckusick.com> Subject: Re: 64-bit inodes (ino64) Status Update and Call for Testing Message-ID: <20170515194145.tx2mp6gxjxbcpbng@mutt-hbsd> In-Reply-To: <20170420194314.GI1788@kib.kiev.ua> References: <20170420194314.GI1788@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--meq5xjd7oh4cv4tt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 <from the Phabricator review | located > 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 ino= 64 >=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. Hey Kostik, On my HardenedBSD system, world compiled fine with the patch, but the kernel didn't compile. I've uploaded the log to: https://hardenedbsd.org/~shawn/2017-05-15_ino64-r01.log This was from importing the patch from Phabricator into hardened/current/master in HardenedBSD. 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 --meq5xjd7oh4cv4tt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlkaBHYACgkQaoRlj1JF bu7DVQ//dkA0Nm4bCMZ0B4Iv3TwZAoWP+EyzLwUAW3ywzM3KhMJyLuGnOIcb+UZ3 szb7jAQEbnOQN3IYsKxKIGmMr0/XFJsdeTGPo29yQ5WFfEpQPZRVkWtC162YrFiE fH9Xuizw3puetGAxlzE3JNM6rBmlJUq0GB1FhUoKlMYD22p6/HTQ3Rn+tJp8oR5R xr0v3F18JcyIbean0RhzXwQZtdTcHpuCL1kgdz+RdrVspY8cw48baJhzburX6ITg XnaU1JSTwWYE58HBfWd6/S5g2/nW9xYfQMNHjuq7vOLPVpy3PWIwelYtcfKMULtt KF/tIsWqPEbPmHhh2BbtzKW95oRruY0M9V8y04cSGFGRaGixXSBJCQ4yQTS0yegy zBpEgY/zZ21MQCrzPIdp7CzfRqWrpIjVS94gska5uER9xI3bq28nWnGwPjeoca4D 5SmNMM6TMWBU2occWwFkaXIURXY+sBxLDbPlBcLGEMkkfm/BajUOrk8YJydCMZeq 73s4b7dKQKWS5Aa18V6Y9/rWMbSQqx/FD7Dvc8rqc49jwv9nRKO6AteEGMvBvKUs NHj1PdeExdtMnuSZd3CFDdTfU0RRy0gqqfISw9ns5aPz0Ofdo9xAjGSEpUGF2Tpu LyX+6X/DlSApPZyC8QsSItKBicuOScXHIQs8AYxX3q7TF8wAbXE= =gxsk -----END PGP SIGNATURE----- --meq5xjd7oh4cv4tt--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170515194145.tx2mp6gxjxbcpbng>