Date: Wed, 20 Mar 2013 11:11:20 -0700 From: Doug Ambrisko <ambrisko@ambrisko.com> To: Alfred Perlstein <bright@mu.org> Cc: arch@FreeBSD.org Subject: Re: Increase the mount path to MAXPATHLEN? Message-ID: <20130320181120.GA52086@ambrisko.com> In-Reply-To: <5149E257.7030906@mu.org> References: <20130319201145.GA19260@ambrisko.com> <20130320211433.F1007@besplex.bde.org> <5149E257.7030906@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130320181120.GA52086>