Fix MNAMELEN or reimplement struct statfs

[Harald Schmalzbauer]

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

Since releng/10.2 is to be created soon, I'm testing RELENG_10 on some
of my production machines, Therefore I cosmetically altered your
patchset to make it work with -stable:
ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/misc/local-patches/RELENG_10/mount_bigger_2_1.patch

Have you made any progress in this area, e.g. is there anything
different I can test, which might help in any way?

Thanks,

-Harry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20150710/6dcb8ced/attachment.bin>