Fix MNAMELEN or reimplement struct statfs

Tue Feb 28 19:54:30 UTC 2017

 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.patch 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,

I hope you are fine!
Nice website, which I checked to see if you gave up on FreeBSD, before
trying to nag you ;-)

<HTML>
<HEAD>
   <TITLE>Welcome Page</TITLE>
   <META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (X11; I; FreeBSD 2.2-CURRENT i386) [Netscape]">

:-) :-) :-)

But I saw r307326, so I thought it's time for my annual "mount_bigger_2_1.patch" status question ;-)

I'm currently planning to upgrade some machines from 10 to 11-stable, where I've been happyly running your patch.
Any updates on the MNAMELEN front? I nearby read about plans to extend it to ?1000:1088?.

But just for now I'd highly appreciate if you could tell me if you are ware of any objections applying your 
mount_bigger_2.patch on 11-stable.

Hope you don't mind if I quote a question from about a year ago:

Bezüglich Harry Schmalzbauer's Nachricht vom 19.11.2015 11:38 (localtime):

…
>> | 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))
>
> …

Do you have anything handy which solves the make_dev_p() limitation?

Greetings,

-harry