From owner-freebsd-fs@FreeBSD.ORG Wed Jun 22 11:01:01 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 23F7E106566B for ; Wed, 22 Jun 2011 11:01:01 +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 B3F8D8FC12 for ; Wed, 22 Jun 2011 11:01:00 +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 p5MB0sGE091764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jun 2011 14:00:54 +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 p5MB0rSA014022; Wed, 22 Jun 2011 14:00:54 +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 p5MB0rrT014021; Wed, 22 Jun 2011 14:00:53 +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: Wed, 22 Jun 2011 14:00:53 +0300 From: Kostik Belousov To: Gleb Kurtsou Message-ID: <20110622110053.GL48734@deviant.kiev.zoral.com.ua> References: <20110621192147.GJ48734@deviant.kiev.zoral.com.ua> <20110622101328.GA19866@tops> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S61UZXTAKvsJ60P5" Content-Disposition: inline In-Reply-To: <20110622101328.GA19866@tops> 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: Wed, 22 Jun 2011 11:01:01 -0000 --S61UZXTAKvsJ60P5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 22, 2011 at 01:13:28PM +0300, Gleb Kurtsou wrote: > On (21/06/2011 22:21), Kostik Belousov wrote: > > 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= mounted */ > > >=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? > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. >=20 > I could do it as part of my 64-bit ino_t GSoC project. So should I > change MNAMELEN to 1024? What about MFSNAMELEN, it's now 16. > I think removing or increasing size of f_charspare field might also be a > good idea. I think it may be good to have this change done. I do think that this is=20 of much lower importance then 64bit ino_t. Also, if done, I prefer to have struct statfs change be separate from ino_t change. That said, statfs change should be much smaller then ino_t, thus easier to review, allowing it to be committed before ino_t. Increasing f_fstypenamehave no obvious benefits, do we expect to have files= ystem types with the names longer then 16 bytes ? I do not think that having much spare fields in struct statfs is definitely good. The structure will become quite large as is after MNAMELEN bump, and the balance should be provided between application memory usage and future extensibility. --S61UZXTAKvsJ60P5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4By2UACgkQC3+MBN1Mb4gArQCfZMdNIQKAO2X6a1jyYKo7x3UL kqwAnRX2UYQ2m58WuP7ODDg4jgcK1wg1 =Ja89 -----END PGP SIGNATURE----- --S61UZXTAKvsJ60P5--