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

git: hammer2 hammer2 - Implement nsymlink, readlink, remove, and rmdir

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 28 Feb 2012 15:48:06 -0800 (PST)

commit 4e2004ea5955eabda0d124fdaf1d28a1766d92db
Author: Matthew Dillon <dillon@apollo.backplane.com>
Date:   Tue Feb 28 15:38:49 2012 -0800

    hammer2 - Implement nsymlink, readlink, remove, and rmdir
    * Implement nsymlink and readlink.  Currently requires VMIO because core
      file r/w procedures are used to read and write the symlink target.
      The symlink target will use inode-embedded data for targets with a
      string length <= 512 bytes.
    * Move a number of functions embedded in VOPs to their own separate
      procedures so they can be called from multiple VOPs.  So far: read,
      write, and remove.  Truncate and extend already had their own
      helper procedures.
    * Implement rm and rmdir.  Currently does not optimize the presence of a
      cached vnode (to get to the ip->chain), but the directory lookup is
      cheap so it might not matter.
      Implement two interesting optmiizations.
      First, free block handling is not done in the active path.  Since we
      never know what snapshots might be pointing deep into our directory
      hierarchy there's no point.  This means that a removal only needs to
      modify the parent chain element pointing to the item.  The item itself
      DOES NOT NEED TO BE MODIFIED IN ANY WAY, even if it is representitive
      of a deep hierarchy (such as if it is a large file).
      Second, recursive removals ala 'rm -rf' can proactive CLEAR the modified
      bit on directory elements being removed that were previously marked
      modified due to removals made from within those elements.
      Together this can reduce the amount of write I/O required to remove a
      directory hierarchy OF ANY SIZE, even terrabytes, to near zero.
    * Hardlinks not yet handled but for the hardlink case the directory entry
      itself will be a dummy and thus can be removed without modification.  The
      related 'real' inode, when we implement hardlinks, will be in some
      parent directory and it will be marked modified.  However, if a rm -rf is
      able to traverse upward through that parent then even the real hardlink
      inode will be re-marked as unmodified and virtually no write I/O will

Summary of changes:
 sys/vfs/hammer2/hammer2_chain.c |   18 ++-
 sys/vfs/hammer2/hammer2_inode.c |   10 +
 sys/vfs/hammer2/hammer2_vnops.c |  413 ++++++++++++++++++++++++++++++++++-----
 3 files changed, 394 insertions(+), 47 deletions(-)


DragonFly BSD source repository

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