From owner-freebsd-arch@FreeBSD.ORG Wed Mar 20 18:11:21 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 7539B624 for ; Wed, 20 Mar 2013 18:11:21 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1B8B49 for ; Wed, 20 Mar 2013 18:11:21 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 20 Mar 2013 11:13:54 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id r2KIBKwC002779; Wed, 20 Mar 2013 11:11:20 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id r2KIBKHq002758; Wed, 20 Mar 2013 11:11:20 -0700 (PDT) (envelope-from ambrisko) Date: Wed, 20 Mar 2013 11:11:20 -0700 From: Doug Ambrisko To: Alfred Perlstein Subject: Re: Increase the mount path to MAXPATHLEN? Message-ID: <20130320181120.GA52086@ambrisko.com> References: <20130319201145.GA19260@ambrisko.com> <20130320211433.F1007@besplex.bde.org> <5149E257.7030906@mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5149E257.7030906@mu.org> User-Agent: Mutt/1.4.2.3i 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 18:11:21 -0000 On Wed, Mar 20, 2013 at 09:22:47AM -0700, Alfred Perlstein wrote: | 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. Okay, looks like I'll have to look into this some more. I wasn't testing with disk file system, just mounting stuff via nullfs, devfs, procfs etc. As for this working before, it seems like on older FreeBSD version like 8.2 if you were in a chroot and did a mount of devfs to a local directory like dest/dev then it worked. If you do it outside then chroot root then it fails. With 9.1 and -current this fails now inside the chroot. mount reports the path as done relative to the chroot. mount in 9.1 reports the full path as if it was outside the chroot. This somewhat makes sense to what I've observed in the past since I use a lot of chroots to as work sand boxes. What I found if I ran build scripts concurrently, that things would get umounted sometimes from the wrong chroot. Maybe due to this being ambigious. Now with full paths being recorded this doesn't seem to happen now. Thanks, Doug A.