HEADS UP - possible destabilization over the next few days

Fri Oct 27 00:35:52 PDT 2006

Matthew Dillon wrote:
    * 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.
Wouldn't this mean that if I mounted a FS in the NULLFS that this mountpoint will also appear in the original tree, or is that managed by nchandles as well?

    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.
Absolutely cool.  When the mount point scanning code is fast enough, I can finally see our VFS enabled package management come true:  just mount all packages you want to see together into one directory.

cheers
 simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low â‚¬â‚¬â‚¬ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20061027/56996fc6/attachment-0020.obj>