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

Re: approach on getting nullfs to work again

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 10 Feb 2005 10:40:53 -0800 (PST)

:On Wed, Feb 09, 2005 at 09:38:15PM -0800, Matthew Dillon wrote:
:>     In fact, *ALL* VOP or VFS ops that specify a file path have the same
:>     ability to distinguish between namespaces as VOP ops that pass namecache
:>     pointers, because path ops will also have access to the related namecache
:>     pointer.
:Matt, shouldn't we fully separate vnode operation affection only the vnode
:(open, close, read, write) from those affection / depending on both
:the name space and the vnode?
:The first kind just has to be looked up and doesn't have to be handled
:by nullfs at all. For unionfs the situation would be a bit more complicated,
:but the underlying filesystem wouldn't have to be aware of unionfs for this
:The second type is more difficult to handle, because the semantic of the
:operation (e.g. mknod or remove or mountctl) can be different for nullfs.
:This operations should be accessed by the mount point of the current
:name cache entry, not the vnode. It would not change the situation
:dramatically for normal filesystems, but allow stackable filesystems to
:just change what they need to change.

    I'm not sure I quite understand what you are getting at but generaly
    speaking I believe that any VOP or VFS op that takes a path argument
    can take a namecache pointer instead.  VOP or VFS ops that take a
    file descriptor, with the exception of VOP or VFS ops that only work
    on the related mount structure, have to take a vnode pointer.

    Nearly all VFS ops operate on the mount point, so its virtually a
    no-brainer.  e.g. statfs.

    For VOP ops I have already converted most or all of the VOP ops that
    can take namecache pointers into actually taking namecache pointers.
    (lookup, create, mkdir, mknod, link, symlink, whiteout, remove, rmdir,

    Now I haven't actually gone out and removed the old VOP ops in most
    filesystems... e.g. UFS still has VOP_CREATE() and its default op
    for VOP_NCREATE() does the namecache resolution and then calls

    But for a nullfs implementation these old VOP ops can be ignored...
    nullfs only has to implement the new VOP ops because the higher level
    system only calls the new VOP ops.  The new vop ops are
    nnresolve, nlookup, ncreate, nmkdir, nmknod, nlink, nsymlink,
    nwhiteout, nremove, nrmdir, and nrename.

					Matthew Dillon 

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