Date: Fri, 10 Jul 2015 08:46:54 -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: <20150710154654.GA71708@ambrisko.com> In-Reply-To: <559FD426.3000108@omnilan.de> References: <20140415233133.GA14686@ambrisko.com> <5452600C.5030003@omnilan.de> <20141101154004.GA40398@ambrisko.com> <559FD426.3000108@omnilan.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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@. | > | | > | 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? It's been working fine for me. Glad to hear it is working good with 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 it a lot at work since we mount things in chroot's of which the path is pretty long especially when we mount stuff in a chroot of chroot for our build process. It's better then my first attempt since the user space ABI didn't change. So it mostly just works except for listing the mount points get truncated. Thanks, Doug A. Thanks, Doug A.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150710154654.GA71708>