git: kernel - Even more buffer cache / VM coherency work
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