Return to new-automounter.mdwn CVS log

Up to [NetBSD Developer Wiki] / wikisrc / projects / project

Fix case DragonflyBSD -> DragonFlyBSD

    1: [[!template id=project
    2: 
    3: title="New automounter"
    4: 
    5: contact="""
    6: [tech-kern](mailto:tech-kern@NetBSD.org)
    7: """
    8: 
    9: mentors="""
   10: """
   11: 
   12: category="filesystems"
   13: difficulty="medium"
   14: duration="3 months"
   15: done_by="Tomohiro Kusumi <tkusumi@netbsd.org> (a port from DragonFlyBSD)"
   16: 
   17: description="""
   18: 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:
   19: 
   20: * 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.
   21: * The automounter daemon cannot handle high I/O load very well; file access occasionally fails with intermittent errors.
   22: * Userland NFS daemons are prone to deadlocking.
   23: 
   24: The milestones of this project are:
   25: 
   26: * implement a new automounter solution which has configurable mount points
   27: * improve behavior under load I/O
   28: * show benchmarks and implement automated tests
   29: 
   30: There are at least two possible approaches: one is to port FreeBSD's
   31: autofs(4), which is an in-kernel file system. This has the advantage
   32: of already existing, and being at least loosely Linux and Solaris
   33: compatible. (One could also write a new autofs but that doesn't seem
   34: like a dominant strategy.)
   35: 
   36: Another possible approach is a new userland daemon using puffs.
   37: 
   38: Note that automount configuration is a complex and largely unsolved
   39: problem. While it's desirable to be compatible with existing
   40: automounter configuration (because often organizations like to
   41: distribute automounter maps through NIS or other facilities) it's also
   42: desirable to have a simple, comprehensible, and cogent configuration
   43: scheme and these desires are rather at odds.
   44: """
   45: ]]