DragonFly BSD
DragonFly kernel List (threaded) for 2006-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: HEADS UP - possible destabilization over the next few days

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 27 Oct 2006 08:01:28 -0700 (PDT)

:Wouldn't this mean that if I mounted a FS in the NULLFS that this mountpo=
:int will also appear in the original tree, or is that managed by nchandle=
:s as well?

    Nope.  The flag in the namecache is just a hint.  For it to look like
    a mount point the system also has to find a mount structure who's
    mnt_ncmounton field matches the {mount,namecache} tuple in order
    to 'push into' a new mount.  The fact that it has to match the
    mount pointer AND the namecache pointer distinguishes the mount point.

    Going backwards with ".." is even easier.  The lookup code detects
    that it is at the base of the current mount and then just reloads
    the lookup cursor with the mnt_ncmounton field.

    Still, please test it.  Any bugs found should be really easy to fix.

:Absolutely cool.  When the mount point scanning code is fast enough, I ca=
:n finally see our VFS enabled package management come true:  just mount a=
:ll packages you want to see together into one directory.
:  simon

    I have an idea on how to make it fast, but I'm going to wait for the
    system to stabilize with this big change before I implement it.  It's
    really simple.. we can either just cache a single forward-looking
    mount in the mount structure of the parent mount, and check the cache
    before doing a scan, or we can formally hash it.  I'm in favor of
    just caching one or two entries.

    So in this environment:


    Someone then opening "/usr/src/sys" would encounter two mount points
    during the path search:  "/usr" and "/usr/src".   "/usr" could be
    cached in "/"'s mount structure and "/usr/src" would be cached in
    "/usr"'s mount structure.  There might be some flip-flopping, e.g.
    "/usr" vs "/tmp" vs "/var", but one or two fixed caching fields 
    would probably be sufficient to cover 99% of the cases efficiently.

    The comparison code is only like four instructions... its just two
    direct pointer comparisons (the mount pointer and the namecache pointer),
    so we are talking about a very fast check either way.

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]