HEADS UP - possible destabilization over the next few days

Matthew Dillon dillon at apollo.backplane.com
Thu Oct 26 16:52:53 PDT 2006


    I am going to be committing a big change to the namecache code
    to fix coherency issues between NULLFS mounts and their underlying
    filesystems.  The commit will occur tonight or tomorrow.  I basically
    have it all working now, but I need to do some cleanups in the NULLFS
    implementation.

    Basically the mount pointer is being moved out of the namecache record
    and all code that uses the namecache will now start using nchandle
    structures, which are basically just { namecache_pointer, mount_pointer }.

    Mount point linkages will be removed from the namecache topology
    entirely.  Each mount will have its own independant topology (except
    for NULLFS mounts, see below).  The lookup code will detect mount
    linkages via a flag in the namecache record and will then scan the
    mountlist to find the linkage (I will optimize this in a followup
    commit).

    This will have several effects:

    * NULLFS mounts will not create a multiplication of namecache entries.
      All NULLFS mounts will share the same namecache topology as their
      underlying filesystems.  A system with a large number of NULLFS mounts
      will use far less kernel memory now.

    * Namecache coherency between a NULLFS mount and its underlying filesystem
      will be maintained.  Since they share the same namecache topology
      there will not be visibility issues or races when a file is created,
      removed, or renamed.

    * No vnode or namecache locks will be maintained when crossing a mount
      boundary, which means that a blockage in one mount shouldn't leak over
      to other mounts.

    It is also my hope that by associating the mount pointer directly with
    the handles that access the name cache (e.g. current dir, root dir,
    jail dir, open descriptors, etc), it will become possible to perform
    mount-specific special actions during lookups that will allow us to
    build a solid union fs or shadowing fs implementation.   I won't be 
    working on those any time soon, but the new infrastructure should make
    the concepts easier to consider.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>





More information about the Kernel mailing list