Date: Tue, 19 Mar 2013 13:11:45 -0700 From: Doug Ambrisko <ambrisko@ambrisko.com> To: arch@freebsd.org Subject: Increase the mount path to MAXPATHLEN? Message-ID: <20130319201145.GA19260@ambrisko.com>
next in thread | raw e-mail | index | archive | help
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. Now there is better error checking and the mounts fail since it exceeds MNAMELEN which was 88. I did notice before that sometimes unmount would unmount other things and could be an issues with multiple scripts running at the same time. This doesn't seem to be a problem now. 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. This means we'll need to create new system calls for stat calls and compatibility. It is a pain, since you need to build and install a new kernel before you can run code with the new values. So there is some pain involved. I've made this change locally on a system and has been running for a few months. However, since other people can add system call numbers then conflicts can be a pain to deal with. So if we are going to do something like this then it would be nice to reserve the new number before someone else grabs them. I'd hate to have a bunch of binaries distributed that could cause major issues like this. I noticed STATFS_VERSION defined as: #define STATFS_VERSION 0x20030518 /* current version number */ I'm not sure if we can use that to change the length without changing the system call number. It also might be good if we had a private system call number range so companies could extend them. I recall we had that for major numbers before devfs. I have a patch at: http://people.freebsd.org/~ambrisko/statf.patch that people can glance at. If this approach is the right way to go then I update it for the latest -current and update it. Right now I'm looking at doing this for an internal 9.1 release and would like to grab the system call numbers so I can make that compatible with the future and have future FreeBSD releases support those binaries. I expect as people starting using chroot/jails/vimage as more general purpose on multi-user machines that more people will run into this. This especially happens if the mount points are in home directories etc. I've now started to spin up light weight vimages via doing a nullfs mount of installworld into a machine name, unionfs a backing store to that and then launch a machine via vimage. A simple script can fire up a new machine quickly. Sometimes these "test" machines are just for routing so the diff between them is really small and is captured in the unionfs backing store. Then I can upgrade them via a new installworld to the source nullfs mount and everything gets the new image. To make this easier to support differnt versions of FreeBSD I have some patches so that in a jail you can change the sysctl for kern.osrelease etc. This is easier then trying to get UNAME_* environment variables set for everything. So I find this really useful. Please let me know if there are better methods to do this. Thanks, Doug A.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130319201145.GA19260>