Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 1 Nov 2014 08:40:04 -0700
From:      Doug Ambrisko <ambrisko@ambrisko.com>
To:        Harald Schmalzbauer <h.schmalzbauer@omnilan.de>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Fix MNAMELEN or reimplement struct statfs
Message-ID:  <20141101154004.GA40398@ambrisko.com>
In-Reply-To: <5452600C.5030003@omnilan.de>
References:  <20140415233133.GA14686@ambrisko.com> <5452600C.5030003@omnilan.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

Doug A.

On Thu, Oct 30, 2014 at 04:58:04PM +0100, Harald Schmalzbauer wrote:
|  Hello,
| 
| first sorry for the missing thread references in the header, I'm not
| subscribed to hackers@.
| 
| 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??
| 
| Thanks,
| 
| -Harry
| 
| 





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141101154004.GA40398>