cvs commit: src/sys/kern vfs_cache.c vfs_syscalls.c vfs_vnops.c vfs_vopops.c src/sys/sys namecache.h stat.h

[Matthew Dillon]

dillon      2005/08/25 11:34:17 PDT

DragonFly src repository

  Modified files:
    sys/kern             vfs_cache.c vfs_syscalls.c vfs_vnops.c 
                         vfs_vopops.c 
    sys/sys              namecache.h stat.h 
  Log:
  Implement FSMID.  Use one of the spare 64 bit fields in the stat structure
  for the FSMID.   The FSMID is a recursively updated field which allows one
  to determine whether a subdirectory hierarchy has changed simply by checking
  the base directory of the desired hierarchy.  The new field is st_fsmid.
  
  The initial implementation stores the FSMID in the namecache, which means that
  the FSMID will indicate a false change if a namecache entry is destroyed and
  recreated.  A more deterministic test can be made by holding a file or
  directory descriptor open.  However, it should be noted that DragonFly
  implements a coherent and hierarchically consistent namecache so simply having
  a subdirectory or file open will prevent the namecache records from that point
  through to the root from being destroyed.
  
  The FSMID can be used to greatly reduce the directories that must be searched
  when synchronizing a filesystem.  The immediate intention is to use it to
  provide a more efficient way to resynchronize a mirror (to generate journal
  records 'diff'ing the current filesystem against a mirror), to improve
  filesystem mirroring utilities, and to provide for an alternative backup
  strategy that involves generating a diff set between two filesystems.
  Normally such schemes would require the entire filesystem to be scanned, but
  with FSMID the number of directories that must be searched can be greatly
  reduced.
  
  TODO: It is desireable for the FSMID information to be stored more permanently
  in the inode to survive reboots and to not return false hits due to namecache
  thrash.
  
  Note that the FSMID facility does not work on an NFS client if the NFS server
  or some other client modifies the filesystem.
  
  Revision  Changes    Path
  1.55      +35 -0     src/sys/kern/vfs_cache.c
  1.70      +11 -0     src/sys/kern/vfs_syscalls.c
  1.31      +12 -2     src/sys/kern/vfs_vnops.c
  1.14      +34 -0     src/sys/kern/vfs_vopops.c
  1.20      +4 -0      src/sys/sys/namecache.h
  1.8       +12 -1     src/sys/sys/stat.h


http://www.dragonflybsd.org/cvsweb/src/sys/kern/vfs_cache.c.diff?r1=1.54&r2=1.55&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/kern/vfs_syscalls.c.diff?r1=1.69&r2=1.70&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/kern/vfs_vnops.c.diff?r1=1.30&r2=1.31&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/kern/vfs_vopops.c.diff?r1=1.13&r2=1.14&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/sys/namecache.h.diff?r1=1.19&r2=1.20&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/sys/stat.h.diff?r1=1.7&r2=1.8&f=u