From owner-freebsd-hackers@freebsd.org Mon Jul 13 04:21:46 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B13E399BE3D for ; Mon, 13 Jul 2015 04:21:46 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 93D5B1EEF; Mon, 13 Jul 2015 04:21:45 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-240-47.lns20.per4.internode.on.net [121.45.240.47]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t6D4BhPi068399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 12 Jul 2015 21:11:47 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <55A33A8A.6070505@freebsd.org> Date: Mon, 13 Jul 2015 12:11:54 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd , Kirk McKusick Subject: Re: Fix MNAMELEN or reimplement struct statfs References: <20140415233133.GA14686@ambrisko.com> <5452600C.5030003@omnilan.de> <20141101154004.GA40398@ambrisko.com> <559FD426.3000108@omnilan.de> <20150710154654.GA71708@ambrisko.com> In-Reply-To: <20150710154654.GA71708@ambrisko.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 04:21:46 -0000 this hits us occasionally too Kirk, you are mentioned here as having a finger in this pie. do we have a suggested way forward? On 7/10/15 11:46 PM, Doug Ambrisko wrote: > 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 > | > | > /|/ > 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. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >