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

["Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>]

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
Description: OpenPGP digital signature