From owner-freebsd-arch@FreeBSD.ORG Wed Mar 20 16:23:05 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 17B3080A for ; Wed, 20 Mar 2013 16:23:05 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E553528B for ; Wed, 20 Mar 2013 16:23:04 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 77E9A1A3D58; Wed, 20 Mar 2013 09:22:54 -0700 (PDT) Message-ID: <5149E257.7030906@mu.org> Date: Wed, 20 Mar 2013 09:22:47 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Bruce Evans Subject: Re: Increase the mount path to MAXPATHLEN? References: <20130319201145.GA19260@ambrisko.com> <20130320211433.F1007@besplex.bde.org> In-Reply-To: <20130320211433.F1007@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:23:05 -0000 On 3/20/13 4:14 AM, Bruce Evans wrote: > On Tue, 19 Mar 2013, Doug Ambrisko wrote: > >> At work we use lots of chroots and mount things within those chroots >> like dev, proc etc. so it looks like a running system. We also do >> some trickery so that we chroot into different versions of FreeBSD >> and pull in some of the native binaries so things like mount, ps etc. >> work inside. We will also create chroots inside that. Since these >> things live in home directories and mount points can be in various >> tree's the mount points are getting pretty long. It seems that >> checking before was weak and let some of these mount worked by accident >> in prior versions of FreeBSD. > >> I'd like to bump the mount point to support a larger value then >> MNAMELEN (88) and to some what avoid this problem in the future thought >> we should just use MAXPATHLEN. I figure that once start hitting that >> limit probably a bunch of things are going to pop up. > > The limited has been hittable for ~30 years, but rarely hit. If it were > important, then it would have been expanded when statfs was expanded to > support 64-bit sizes on 32-bit systems. Instead, the pathname arrays > have shrunk a bit since 4.4BSD where they had size 90. Before that, > bits of the pathnames were bitten off to make space for more important > fields, and the array size was reduced to 80 in struct ostatfs. THe > current struct statfs just unbites for these fields and expands back to > size 80. > > Does using MAXPATHLEN even fix the problem? Absolute pathnames much > longer than it can be constructed using relative paths starting in > a deep directory, or symlinks. I think mount(2) handle relative paths, > but mount(8) uses realpath(3) and the latter is almost necessary for > making the pathnames returned by statfs() usable. realpath() is broken > as designed. It repeats the design errors of getwd() and only supports > pathname lengths of < {PATH_MAX}. This "fixes" the problem that the > path length might be longer than that by not supporting such paths. > > NetBSD "fixed" this long ago by keeping struct statfs unchanged but > deprecated, but using _VFS_MNAMELEN = 1024 in struct statvfs. In > FreeBSD, > statvfs() and struct statvfs are just minimal compatibility cruft, with > no names at all in the struct since names are nonstandard. This is the approach I would hope to see happen. Making a separate syscall/method to return a MAXPATHLEN mount path based on fsid would be very easy and result in a lot less compat cruft. I think it's time to deprecate retrieval of the mount paths via statfs and instead use another call as do most other unix-like OSes. -Alfred