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

git: kernel - Even more buffer cache / VM coherency work


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 28 Jan 2010 09:13:04 -0800 (PST)

commit 6362a262e633b546c510362dad6fd7adfea9f32e
Author: Matthew Dillon <dillon@apollo.backplane.com>
Date:   Thu Jan 28 09:04:34 2010 -0800

    kernel - Even more buffer cache / VM coherency work
    
    * nvtruncbuf/nvextendbuf now clear the cached layer 2 disk offset
      from the buffer cache buffer being zero-extended or zero-truncated.
      This is required by HAMMER since HAMMER never overwrites data
      in the same media block.
    
    * Convert HAMMER over to the new nvtruncbuf/nvextendbuf API.
    
      The new API automatically handles zero-truncations and zero-extensions
      within the buffer straddling the file EOF and also changes the way
      backing VM pages are handled.  Instead of cutting the VM pages off
      at the nearest boundary past file EOF any pages in the straddling
      buffer are left fully valid and intact, which avoids numerous pitfalls
      the old API had in dealing with VM page valid/dirty bits during
      file truncations and extensions.
    
    * Make sure the PG_ZERO flag in the VM page is cleared in allocbuf().
    
    * Refactor HAMMER's strategy code to close two small windows of
      opportunity where stale data might be read from the media.  In
      particular, refactor hammer_ip_*_bulk(), hammer_frontend_trunc*(),
      and hammer_io_direct_write().  These were detected by the fsx test
      program on a heavily paging system with physical memory set artificially
      low.
    
      Data flows through three stages in HAMMER:
    
      (1) Buffer cache.
    
      (2) In-memory records referencing the direct-write data offset on the
          media until the actual B-Tree is updated on-media at a later time.
    
      (3) Media B-Tree lookups referencing the committed data offset on the
          media.
    
      HAMMER must perform a careful, fragile dance to ensure that access to
      the data from userland doesn't slip through any cracks while the data
      is transitioning between stages.  Two cracks were found and fixed:
    
      (A) The direct-write code was allowing the BUF/BIO in the strategy
          call to complete before adding the in-memory record to the index
          for the stage 1->2 transition.  Now fixed.
    
      (B) The HAMMER truncation code was skipping in-memory records queued
          to the backend flusher under the assumption that the backend
          flusher would deal with them, which it will eventually, but there
          was a small window where the data was still accessible by userland
          after the truncation if userland did a truncation followed by an
          extension.  Now fixed.

Summary of changes:
 sys/kern/vfs_bio.c             |    1 +
 sys/kern/vfs_vm.c              |   10 +++
 sys/vfs/hammer/hammer.h        |    6 +-
 sys/vfs/hammer/hammer_inode.c  |    9 +--
 sys/vfs/hammer/hammer_io.c     |   25 ++++----
 sys/vfs/hammer/hammer_object.c |  119 ++++++++++++++++++++++++----------------
 sys/vfs/hammer/hammer_subs.c   |    9 +++
 sys/vfs/hammer/hammer_vnops.c  |   87 +++++++++++++++--------------
 8 files changed, 156 insertions(+), 110 deletions(-)

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/6362a262e633b546c510362dad6fd7adfea9f32e


-- 
DragonFly BSD source repository



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