Date: Wed, 22 Jun 2011 13:13:28 +0300 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: bumping mount path lengths in struct statfs Message-ID: <20110622101328.GA19866@tops> In-Reply-To: <20110621192147.GJ48734@deviant.kiev.zoral.com.ua> References: <BANLkTimoRaqJ-4KbBh7-jC5Z8-160-V%2BdA@mail.gmail.com> <20110621192147.GJ48734@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On (21/06/2011 22:21), Kostik Belousov wrote: > On Tue, Jun 21, 2011 at 09:16:18AM -0600, Will Andrews wrote: > > Hi, > > > > struct statfs contains the following: > > > > 90 char f_mntfromname[MNAMELEN]; /* mounted filesystem */ > > 91 char f_mntonname[MNAMELEN]; /* directory on which mounted */ > > > > 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. 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. Thanks, Gleb.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110622101328.GA19866>