On Thu, 2007-05-31 at 18:29 +0200, Miklos Szeredi wrote: > I started working on adding support for unprivileged mounts[1] to > util-linux. > > The big obstacle seems to be the reliance on /etc/mtab, since that > won't be kept up-to-date after mount(2) or umount(2) calls by > unprivileged users. snip ... > Can someone think of any other problem with getting rid of /etc/mtab? This presents a couple of problems for autofs, version 5. First, autofs will function if /etc/mtab is a symlink to /proc/mounts (or better if we could mount /proc/mounts as the "file" /etc/mtab). There are however two problems, first for people that have a large number of mounts, particularly direct mounts, the listing of mounts would be terrible. An implementation of automount on an old version of AIX did this and it was just about impossible to tell what mounts where present besides the autofs internal mounts. Solaris uses a mount option, "hide" or "hidden" or something which prevents them from being listed and that works fine. We would need to do something like that in all the utilities that read /etc/mtab. The second, and also maybe not such a big issue, is that if there are many autofs entries to read through this has the potential to kill autofs performance for mounting, expiring and checking if something is mounted, whether the entries have a hidden flag or not utilities will still need to read through all the entries. The same performance issue applies for all the utilities that read the mount table. I'd expect a typical small to medium site that makes wide use of direct mounts to have between 500 and 1000 entries in their maps, and so 500 - 1000 autofs direct mount triggers, similar to Solaris. Also, people that have large filers with many exports will have many internal autofs mounts if using the commonly used "hosts" map, we use a different implementation for this than Solaris so there are less internal autofs mounts than in Solaris, but still many. Ideas? Ian - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
