Re: approach on getting nullfs to work again

看板DFBSD_kernel作者時間21年前 (2005/02/11 03:01), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串14/15 (看更多)
:On Wed, Feb 09, 2005 at 09:38:15PM -0800, Matthew Dillon wrote: :> :okay. this means all vop calls that don't work with struct namecache *=20 :> :parameters just get passed through to the underlying filesystem and all vop= :> :=20 :> :calls that cope with struct namecache * need to wrap, grab the "real"=20 :> :namecache entry and pass it down? :> :> VOP calls, yes. VFS calls (as Joerg indicates, fstatfs) might be a :> different matter, but even there the best solution might actually be :> a high level kernel solution ('gee this path is going through a nullfs :> mount') rather then a low level VFS solution. It could be just a matter :> of adding an ncp argument to the VFS op in question. : :What happens if we use the namecache entry in fp->f_data and follow that :to the actual vnode before VOP calls? Even including a namecache entry :directly in f_data and setting it to NULL for sockets? This won't work because an active vnode will not always have a namecache association. e.g. if you open() a file and then remove() the file. This is why there is a separate f_ncp. A namecache pointer will not be destroyed while a reference is held on it, and will not be invalidated while held locked (except by the holder), but it can still be invalidated at any other time and it's nc_vp vnode association *WILL* be destroyed in that case. Furthermore, in the case of rename() and other operations if you are e.g. renaming-over a target file, the namecache pointer associated with the original target will be marked destroyed and can *never* be reconstituted (at least not as an assocition with the original target vnode which is no longer in the namespace). So a namecache pointer is not a direct replacement for a vnode. :> 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. : :Yeah, so we would want to convert the VFS calls to get a namecache entry :as well. If we have that, I don't have any problems with using the vnodes :directly. : :Joerg Possibly, yes. I would call that 'stage 2' or 'stage 3'. ncp->nc_mount should be consistent now because, amoung other things, all the VOP_*() compatibility macros are now getting the ops structure via ncp->nc_mount->mnt_vn_use_ops. This means that a resolved and locked namecache pointer can replace the use of a mount pointer in most VFS calls. -Matt Matthew Dillon <dillon@backplane.com>
文章代碼(AID): #122wzy00 (DFBSD_kernel)
討論串 (同標題文章)
文章代碼(AID): #122wzy00 (DFBSD_kernel)