A new unionfs has been committed.  It fixes a whole lot of things,
    but due to the complexity of the commit people should consider
    unionfs to be unstable and under test.  I will say, though, that
    unionfs was terribly unstable before the commit and there is very
    little that I could have done to actually make it worse :-)

    There is an interesting story behind this commit.  I had actually tried
    to fix unionfs around a month ago, believing it would be relatively
    simple.  After several days of hacking I was no closer to making things
    work better and gave up.  This time around I approached unionfs from
    the "everything must be broken" point of view and went through the
    whole source with a fine toothed comb, rewriting and commenting much of
    it .

    My eventual goal is to be able to mount unionfs on / and have it
    work so well as to be transparent.  It's always nice to have an 
    unattainable goal (consider what unionfs would have to do if you 
    renamed a backing store directory, for example!).

    My near-term goal is to be able to use unionfs for diskless 
    configurations, with read-only NFS mounts as backing store and
    swap-backed VN based filesystems as fronting store.  The idea
    is to make the diskless workstation work exactly like a normal
    server except that you lose everything when you reboot.

    In anycase, this is a rough but still relatively complete commit.  
    unionfs is being actively worked on at the moment, and Tor is working 
    on nullfs.

    The most common bug still probably in unionfs is a deadlock that may
    lockup the processes using unionfs, but hopefully will not effect
    processes not using unionfs.  Warning: if you have /usr/src mounted
    with unionfs you cannot gdb -k your active system because gdb will
    try to access the source files under /usr/src and lockup along with
    the rest of the unionfs related processes :-)

                                                -Matt


dillon      1999/09/26 13:52:42 PDT

  Modified files:
    sys/miscfs/union     union.h union_subr.c union_vfsops.c 
                         union_vnops.c 
  Log:
      This is a major fixup of unionfs.  At least 30 serious bugs have been
      fixed (many due to changing semantics in other parts of the kernel and not
      the original author's fault), including one critical one: unionfs could
      cause UFS corruption in the fronting store due to calling VOP_OPEN for
      writing without turning on vmio for the UFS vnode.
  
      Most of the bugs were related to semantics changes in VOP calls, lock
      ordering problems (causing deadlocks), improper handling of a read-only
      backing store (such as an NFS mount), improper referencing and locking
      of vnodes, not using real struct locks for vnode locking, not using
      recursive locks when accessing the fronting store, and things like that.
  
      New functionality has been added:  unionfs now has mmap() support, but
      only partially tested, and rename has been enhanced considerably.
  
      There are still some things that unionfs cannot do.   You cannot
      rename a directory without confusing unionfs, and there are issues
      with softlinks, hardlinks, and special files.  unionfs mostly doesn't
      understand them (and never did).
  
      There are probably still panic situations, but hopefully no where near
      as many as before this commit.
  
      The unionfs in this commit has been tested overlayed on /usr/src
      (backing /usr/src being a read-only NFS mount, fronting /usr/src being
      a local filesystem).  kernel builds have been tested, buildworld is
      undergoing testing.  More testing is necessary.
  
  Revision  Changes    Path
  1.15      +37 -10    src/sys/miscfs/union/union.h
  1.40      +349 -197  src/sys/miscfs/union/union_subr.c
  1.36      +58 -68    src/sys/miscfs/union/union_vfsops.c
  1.64      +818 -588  src/sys/miscfs/union/union_vnops.c





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to