svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libmi...

Konstantin Belousov kib at freebsd.org
Tue Mar 12 22:40:06 UTC 2019


On Tue, Mar 12, 2019 at 04:22:35PM -0600, Alan Somers wrote:
> On Tue, Mar 12, 2019 at 4:20 PM Konstantin Belousov <kib at freebsd.org> wrote:
> >
> > On Tue, Mar 12, 2019 at 03:58:31PM -0600, Alan Somers wrote:
> > > On Tue, May 23, 2017 at 3:29 AM Konstantin Belousov <kib at freebsd.org> wrote:
> > > >
> > > > Author: kib
> > > > Date: Tue May 23 09:29:05 2017
> > > > New Revision: 318736
> > > > URL: https://svnweb.freebsd.org/changeset/base/318736
> > > >
> > > > Log:
> > > >   Commit the 64-bit inode project.
> > > >
> > > >   Extend the ino_t, dev_t, nlink_t types to 64-bit ints.  Modify
> > > >   struct dirent layout to add d_off, increase the size of d_fileno
> > > >   to 64-bits, increase the size of d_namlen to 16-bits, and change
> > > >   the required alignment.  Increase struct statfs f_mntfromname[] and
> > > >   f_mntonname[] array length MNAMELEN to 1024.
> > > >
> > > >   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 ways.
> > > >
> > > >   Kinfo sysctl MIBs ABI is changed in backward-compatible way, but
> > > >   there is no general mechanism to handle other sysctl MIBS which
> > > >   return structures where the layout has changed. It was considered
> > > >   that the breakage is either in the management interfaces, where we
> > > >   usually allow ABI slip, or is not important.
> > > >
> > > >   Struct xvnode changed layout, no compat shims are provided.
> > > >
> > > >   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 64-bit dev_t, for the sake of pstat.
> > > >
> > > >   Update note: strictly follow the instructions in UPDATING.  Build
> > > >   and install the new kernel with COMPAT_FREEBSD11 option enabled,
> > > >   then reboot, and only then install new world.
> > > >
> > > >   Credits: The 64-bit inode project, also known as ino64, started life
> > > >   many years ago as a project by Gleb Kurtsou (gleb).  Kirk McKusick
> > > >   (mckusick) then picked up and updated the patch, and acted as a
> > > >   flag-waver.  Feedback, suggestions, and discussions were carried
> > > >   by Ed Maste (emaste), John Baldwin (jhb), Jilles Tjoelker (jilles),
> > > >   and Rick Macklem (rmacklem).  Kris Moore (kris) performed an initial
> > > >   ports investigation followed by an exp-run by Antoine Brodin (antoine).
> > > >   Essential and all-embracing testing was done by Peter Holm (pho).
> > > >   The heavy lifting of coordinating all these efforts and bringing the
> > > >   project to completion were done by Konstantin Belousov (kib).
> > > >
> > > >   Sponsored by: The FreeBSD Foundation (emaste, kib)
> > > >   Differential revision:        https://reviews.freebsd.org/D10439
> > >
> > > What's the purpose of the new dirent.d_off field?  I can't find any
> > > code that uses it.
> > It is supposed to help NFS server.  They are supposed to provide directly the
> > cookies for nfs readdir call. But it is not required, and corresponding
> > code was not committed to FreeBSD fs/nfs yet.
> >
> > > I'm wondering if the fuse(4) module should set it
> > > in order to work properly over NFS, or something.
> >
> > No, it is not strictly required.  OTOH, there is userspace implementation
> > of NFS server which seems to make use of it when available.  This is why
> > r340431 was done.
> 
> Would that be unfs3 or nfs-ganesha?  I might add it to my list of stuff to test.
ganesha.


More information about the svn-src-head mailing list