bumping mount path lengths in struct statfs

[Gleb Kurtsou]

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.