Re: nnull

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:On 2006-01-02, Csaba Henk <csaba.henk@xxxxxxx> wrote:
:> I just posted two patches to submit@ which make nullfs work with the new
:> namecache API (yes, it's without vnode overlaying).
:
:Anchors for the future:
:
:http://leaf.dragonflybsd.org/mailarchive/submit/2006-01/msg00000.html
:http://leaf.dragonflybsd.org/mailarchive/submit/2006-01/msg00001.html
:
:Csaba

    What a nice Christmas present!  I was hoping someone would come along
    and rewrite nullfs!

    The unmount patch also looks good.  I see you are able to avoid 
    calling vget by using nc_mount, which is possible now that the 
    unmount code passes around mount structures instead of vnodes.  Great!

    I will get these into HEAD today.  It won't make it into 1.4 for
    the release but it will make it into a future update.

    There is one issue with regards to overlayed namecache entries.
    The issue occurs when you try to do a rename() or other namespace 
    operation and you have multiple namecache records refering to the
    same physical namespace.  Since rename() locks the namespace by locking
    the related namecache records, it becomes possible for a namespace
    operation in the nullfs layer to race a namespace operation in the
    underlying filesystem layer.  The system probably wouldn't be too happy
    when this happens.

    But, as I said, this issue is more the responsibility of the namecache
    locking layer then the filesystem layer.  In order to make it work
    properly we'll probably need to extend the namecache structure to
    recognize the difference between an overlay and a base filesystem
    entry and to have the overlay also lock the base filesystem entry
    (if present).  Plus there would need to be a deadlock detector.  Not a
    trivial problem, but at least one that can be encapsulated within the
    namecache implementation.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>