git: hammer2 - Fix inode nlinks / directory-entry desynchronization on crash

Matthew Dillon dillon at
Fri Sep 15 10:29:31 PDT 2017

commit 7220df841c67fe5a322bcc772a1c3b6c2b69739c
Author: Matthew Dillon <dillon at>
Date:   Fri Sep 15 10:21:14 2017 -0700

    hammer2 - Fix inode nlinks / directory-entry desynchronization on crash
    * Hammer2 must flush dirty inodes, buffers, and chains when doing a sync,
      before writing-out the volume header.
    * Inodes are flushed in two stages... we flush inodes via vfsyncscan()
      which runs through dirty vnodes, but inodes disassociated from vnodes
      are recorded separately and must also be flushed.  This is handled by
    * Fix an ordering bug where hammer2_inode_run_sideq() was being called
      before vfsyncscan() instead of after.  This could result in some dirty
      inodes slipping through the cracks by getting retired by the system
      after the hammer2_inode_run_sideq() call but before vfsyncscan() can
      get to them.
      Fixed by calling hammer2_inode_run_sideq() after vfsyncscan() instead
      of before.
      Note that vnodes cannot normally be dirtied during the serialized portion
      of the flush because the flush serializes against modifying VOPs.  So we
      should not have a second source of desynchronization from that sort of
      activity.  In fact, strategy calls via shared R/W mmap()'s can execute
      concurrent with a flush, but these will have no effect on inode size
      or nlinks.

Summary of changes:
 sys/vfs/hammer2/hammer2_vfsops.c | 17 +++++++++++++----
 sys/vfs/hammer2/hammer2_vnops.c  | 20 ++++++++------------
 2 files changed, 21 insertions(+), 16 deletions(-)

DragonFly BSD source repository

More information about the Commits mailing list