From owner-freebsd-fs@FreeBSD.ORG Tue Jun 21 19:21:53 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4D351065689 for ; Tue, 21 Jun 2011 19:21:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1995D8FC14 for ; Tue, 21 Jun 2011 19:21:52 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p5LJLlXR096684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jun 2011 22:21:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p5LJLlQr080914; Tue, 21 Jun 2011 22:21:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p5LJLlPE080913; Tue, 21 Jun 2011 22:21:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 21 Jun 2011 22:21:47 +0300 From: Kostik Belousov To: Will Andrews Message-ID: <20110621192147.GJ48734@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrl79+UYnlG4XqVU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: bumping mount path lengths in struct statfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 19:21:53 -0000 --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--