Print this page
        
@@ -19,11 +19,11 @@
  * CDDL HEADER END
  */
 
 /*
  * Copyright (c) 1988, 2010, Oracle and/or its affiliates. All rights reserved.
- * Copyright 2016 Joyent, Inc.
+ * Copyright (c) 2014, Joyent, Inc. All rights reserved.
  */
 
 /*      Copyright (c) 1983, 1984, 1985, 1986, 1987, 1988, 1989 AT&T     */
 /*        All Rights Reserved   */
 
@@ -219,63 +219,10 @@
  *
  * ALL OTHER FIELDS SHOULD BE ACCESSED ONLY BY THE OWNER OF THAT FIELD.
  * In particular, file systems should not access other fields; they may
  * change or even be removed.  The functionality which was once provided
  * by these fields is available through vn_* functions.
- *
- * VNODE PATH THEORY:
- * In each vnode, the v_path field holds a cached version of the canonical
- * filesystem path which that node represents.  Because vnodes lack contextual
- * information about their own name or position in the VFS hierarchy, this path
- * must be calculated when the vnode is instantiated by operations such as
- * fop_create, fop_lookup, or fop_mkdir.  During said operations, both the
- * parent vnode (and its cached v_path) and future name are known, so the
- * v_path of the resulting object can easily be set.
- *
- * The caching nature of v_path is complicated in the face of directory
- * renames.  Filesystem drivers are responsible for calling vn_renamepath when
- * a fop_rename operation succeeds.  While the v_path on the renamed vnode will
- * be updated, existing children of the directory (direct, or at deeper levels)
- * will now possess v_path caches which are stale.
- *
- * It is expensive (and for non-directories, impossible) to recalculate stale
- * v_path entries during operations such as vnodetopath.  The best time during
- * which to correct such wrongs is the same as when v_path is first
- * initialized: during fop_create/fop_lookup/fop_mkdir/etc, where adequate
- * context is available to generate the current path.
- *
- * In order to quickly detect stale v_path entries (without full lookup
- * verification) to trigger a v_path update, the v_path_stamp field has been
- * added to vnode_t.  As part of successful fop_create/fop_lookup/fop_mkdir
- * operations, where the name and parent vnode are available, the following
- * rules are used to determine updates to the child:
- *
- * 1. If the parent lacks a v_path, clear any existing v_path and v_path_stamp
- *    on the child.  Until the parent v_path is refreshed to a valid state, the
- *    child v_path must be considered invalid too.
- *
- * 2. If the child lacks a v_path (implying v_path_stamp == 0), it inherits the
- *    v_path_stamp value from its parent and its v_path is updated.
- *
- * 3. If the child v_path_stamp is less than v_path_stamp in the parent, it is
- *    an indication that the child v_path is stale.  The v_path is updated and
- *    v_path_stamp in the child is set to the current hrtime().
- *
- *    It does _not_ inherit the parent v_path_stamp in order to propagate the
- *    the time of v_path invalidation through the directory structure.  This
- *    prevents concurrent invalidations (operating with a now-incorrect v_path)
- *    at deeper levels in the tree from persisting.
- *
- * 4. If the child v_path_stamp is greater or equal to the parent, no action
- *    needs to be taken.
- *
- * Note that fop_rename operations do not follow this ruleset.  They perform an
- * explicit update of v_path and v_path_stamp (setting it to the current time)
- *
- * With these constraints in place, v_path invalidations and updates should
- * proceed in a timely manner as vnodes are accessed.  While there still are
- * limited cases where vnodetopath operations will fail, the risk is minimized.
  */
 
 struct fem_head;        /* from fem.h */
 
 typedef struct vnode {
@@ -298,11 +245,10 @@
         krwlock_t       v_nbllock;      /* sync for NBMAND locks */
         kcondvar_t      v_cv;           /* synchronize locking */
         void            *v_locality;    /* hook for locality info */
         struct fem_head *v_femhead;     /* fs monitoring */
         char            *v_path;        /* cached path */
-        hrtime_t        v_path_stamp;   /* timestamp for cached path */
         uint_t          v_rdcnt;        /* open for read count  (VREG only) */
         uint_t          v_wrcnt;        /* open for write count (VREG only) */
         u_longlong_t    v_mmap_read;    /* mmap read count */
         u_longlong_t    v_mmap_write;   /* mmap write count */
         void            *v_mpssdata;    /* info for large page mappings */
@@ -1345,15 +1291,10 @@
 void vn_setpath_str(struct vnode *vp, const char *str, size_t len);
 void vn_setpath(vnode_t *rootvp, struct vnode *startvp, struct vnode *vp,
     const char *path, size_t plen);
 void vn_renamepath(vnode_t *dvp, vnode_t *vp, const char *nm, size_t len);
 
-/* Private vnode manipulation functions */
-void vn_clearpath(vnode_t *, hrtime_t);
-void vn_updatepath(vnode_t *, vnode_t *, const char *);
-
-
 /* Vnode event notification */
 void    vnevent_rename_src(vnode_t *, vnode_t *, char *, caller_context_t *);
 void    vnevent_rename_dest(vnode_t *, vnode_t *, char *, caller_context_t *);
 void    vnevent_remove(vnode_t *, vnode_t *, char *, caller_context_t *);
 void    vnevent_rmdir(vnode_t *, vnode_t *, char *, caller_context_t *);
@@ -1398,13 +1339,10 @@
 /* Context identification */
 u_longlong_t    fs_new_caller_id();
 
 int     vn_vmpss_usepageio(vnode_t *);
 
-/* Empty v_path placeholder */
-extern char *vn_vpath_empty;
-
 /*
  * Needed for use of IS_VMODSORT() in kernel.
  */
 extern uint_t pvn_vmodsort_supported;