--- wikisrc/projects/project/new-automounter.mdwn 2016/08/26 07:45:45 1.1 +++ wikisrc/projects/project/new-automounter.mdwn 2019/12/14 07:45:06 1.10 @@ -1,10 +1,9 @@ [[!template id=project -title="Improved Automounter Support" +title="New automounter" contact=""" -[tech-kern](mailto:tech-net@NetBSD.org), -[tech-net](mailto:tech-net@NetBSD.org) +[tech-kern](mailto:tech-kern@NetBSD.org) """ mentors=""" @@ -13,21 +12,34 @@ mentors=""" category="filesystems" difficulty="medium" duration="3 months" +done_by="Tomohiro Kusumi <> (a port from DragonFlyBSD which was a port from FreeBSD)" description=""" NetBSD currently uses amd for automatically mounting (network) file systems. This software package implements an automounter file system as a userland NFS daemon. While this generally works it has major drawbacks: * File systems are not mounted directly on the desired mount point. As a result applications frequently use incorrect pathnames (e.g. `/amd/server/home/user` instead of `/home/user`) for automatically mounted directories or files beneath them. This is especially problematic in heterogeneous enviroments where not all machines use the same automounter. * The automounter daemon cannot handle high I/O load very well; file access occasionally fails with intermittent errors. +* Userland NFS daemons are prone to deadlocking. The milestones of this project are: * implement a new automounter solution which has configurable mount points -* improve high I/O +* improve behavior under load I/O * show benchmarks and implement automated tests -This could either be done via a Solaris/Linux compatible autofs(4) full in-kernel file system. FreeBSD has already implemented autofs, so we could port theirs and that should significantly simplify the project. +There are at least two possible approaches: one is to port FreeBSD's +autofs(4), which is an in-kernel file system. This has the advantage +of already existing, and being at least loosely Linux and Solaris +compatible. (One could also write a new autofs but that doesn't seem +like a dominant strategy.) + +Another possible approach is a new userland daemon using puffs. + +Note that automount configuration is a complex and largely unsolved +problem. While it's desirable to be compatible with existing +automounter configuration (because often organizations like to +distribute automounter maps through NIS or other facilities) it's also +desirable to have a simple, comprehensible, and cogent configuration +scheme and these desires are rather at odds. """ ]] - -[[!tag gsoc]]