Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Jun 2011 22:21:47 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Will Andrews <will@firepipe.net>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: bumping mount path lengths in struct statfs
Message-ID:  <20110621192147.GJ48734@deviant.kiev.zoral.com.ua>
In-Reply-To: <BANLkTimoRaqJ-4KbBh7-jC5Z8-160-V%2BdA@mail.gmail.com>
References:  <BANLkTimoRaqJ-4KbBh7-jC5Z8-160-V%2BdA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--yrl79+UYnlG4XqVU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 21, 2011 at 09:16:18AM -0600, Will Andrews wrote:
> Hi,
>=20
> struct statfs contains the following:
>=20
>  90         char      f_mntfromname[MNAMELEN];  /* mounted filesystem */
>  91         char      f_mntonname[MNAMELEN];    /* directory on which mou=
nted */
>=20
> Where MNAMELEN is, currently, 88.  These limit the length of the path
> that a filesystem can be mounted to.  This is enforced by
> kern/vfs_mount.c:vfs_donmount().  This limit seems archaic, especially
> given use cases like virtualization (large filesystem structures to
> support underlying VMs), builds (which often make extensive use of
> chroot with nullfs/NFS), ZFS, snapshots, etc.  Does anyone object to
> bumping MNAMELEN to 1024 (PATH_MAX/MAXPATHLEN)?  Or some other
> reasonably large value?

There is nothing inherently wrong with bumping the length. But the
work required is probably more then you estimated. The cause is the
ABI breakage. For sure, you will need to provide the shims for compat
syscalls. Unfortunately, this is not enough.

Even quick look over our tree shows that struct statfs is used in API by
several base libraries. Look e.g. at the getmntinfo(3). Libc would need
shims too, at least.

You will need to do the ABI analisys of the whole system, provide the
shims for the symbol-versioned libraries, and bump so version for
unversioned.


--yrl79+UYnlG4XqVU
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iEYEARECAAYFAk4A70sACgkQC3+MBN1Mb4huPwCdH5mvpBYrrnFL7Ds70PC35t7B
MucAoOw3rzemUoPU/vbDoYQpl4751Rn+
=6KW5
-----END PGP SIGNATURE-----

--yrl79+UYnlG4XqVU--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110621192147.GJ48734>