Fix MNAMELEN or reimplement struct statfs

[Harry Schmalzbauer]

 Bezüglich Doug Ambrisko's Nachricht vom 10.07.2015 17:46 (localtime):
> On Fri, Jul 10, 2015 at 04:18:14PM +0200, Harald Schmalzbauer wrote:
> | 
> | > |  Hello,
> | > | 
> | > | first sorry for the missing thread references in the header, I'm not
> | > | subscribed to hackers at .
> | > | 
> | > | bdrewery@ pointed me to this discussion in response to my question to
> | > | stable@
> | > | (http://lists.freebsd.org/pipermail/freebsd-fs/2014-August/019949.html)
> | > | 
> | > | Last promising post I found:
> | > | 
> | > | > |/ > I have a new patch at:
> | > | > /|/ > 	http://people.freebsd.org/~ambrisko/mount_bigger_2.patch <http://people.freebsd.org/%7Eambrisko/mount_bigger_2.patch>
> | > | > /|/ > that I tested against head.  This should be pretty close to commiting
> | > | > /|/ > unless people find some issues with it.
> | > | > /|/ 
> | > | > /|/ In sys/kern/vfs_mount.c:
> | > | > /|/ +		mp->mnt_path = malloc(strlen(fspath), M_MOUNT, M_WAITOK);
> | > | > /|/ +		strlcpy((char *)mp->mnt_path, fspath, strlen(fspath));
> | > | > /|/ 
> | > | > /|/ This always strips the last byte off the fspath.
> | > | > /|/ 
> | > | > /|/ I like that this only touches the kernel, so it does not break anything
> | > | > /|/ regarding mount/umount of filesystems with short paths, including
> | > | > /|/ (NFS) filesystems that do not respond.
> | > | > /|/ 
> | > | > /|/ The patch does not enlarge f_mntfromname which may be a problem for
> | > | > /|/ nullfs. It is certainly a step forwards for poudriere but [ENAMETOOLONG]
> | > | > /|/ errors could still occur in more extreme situations.
> | > | > /
> | > | > Good point on nullfs.  I'll look at fixing that.  To do that I'm
> | > | > changing mnt_path to mnt_topath so then I can have a mnt_frompath.
> | > | > I'll add nullfs to my test cases.  I'll need to run through the uses
> | > | > of f_mntfromname.  It was pretty easy with f_mntonname since it was
> | > | > only allocated in one place just used a bunch of other place.  I assume
> | > | > that mount root would be short.
> | > | 
> | > | Thanks a lot so far for working hard on that problem!
> | > | Is there anything newer than "mount_bigger_2.patch", which considers
> | > | potential nullfs problems?
> | > | I'm heavily using nullfs (without poudriere), but I'd give it a try on
> | > | my rather lightly loaded local 10.1 storage box ??? almost all snapshots
> | > | are useless, can't access them in case of the case; which happens
> | > | frequently :-(
> | > | Would I have to expect any nullfs regressions with the april
> | > | (mount_bigger_2) patch??
> | 
> | Bez?glich Doug Ambrisko's Nachricht vom 01.11.2014 16:40 (localtime):
> | > I should be able to resume working on this since things are starting to
> | > slow down.  It shouldn't be much more work to get it finished off to
> | > put up for review.
> | 
> | Hello Doug,
> | 
> | I've been using your mount_bigger_2.path for some months without
> | problems, but haven't done any kind of stress test.
> | It just saves my soul in case I have to recover files from
> | (zfs-)snapshots from time to time :-)

Hello Doug,

unfortunately, mount_bigger doesn't cover the length restriction for
make_dev_p(), which leads to inaccessable zvols
(g_dev_taste: make_dev_p() failed
(gp->name=zvol/babasP0.1xSATA7k2-0/liveBACKSTOR/zfsREPL/esm-vega/P1/iscsi.redtsdatahdd500 at epochp2,
error=63))

…
> ZFS.  Kirk asked me not to continue with this since it would make
> the 64 bit inode work harder and that they were going to bump up
> the max of the mount point.  He also mentioned that it couldn't be
> merged back since it changes the kernel API.  So I'm not sure
> where that leaves us for now except that this works for us.   I use
…

Do you have any news regarding this issue?
I haven't followed the whole development in that area for quiet some
time, but just tried 10/stable (r290995) and found this beeing still
unresolved.

Thanks,

-Harry