[DragonFlyBSD - Bug #3269] (In Progress) Is double-buffer'd buf still required by HAMMER2 ?

[bugtracker-admin at leaf.dragonflybsd.org]

Issue #3269 has been updated by dillon.

Status changed from New to In Progress

Unfortunately we have to continue to double-buffer for several reasons.  The main reason is that H2 compresses data by default so the device buffer will contain the compressed data while the filesystem buffer will contain the uncompressed data.  A second reason relates to how the de-duplication code operates.  We cannot safely de-duplicate against a filesystem buffer because the contents of a filesystem buffer can be memory-mapped by userland and directly modified.  There are numerous other reasons as well... for example, small files are still packed in blocks as small as 2KB so caching many small files is relatively optimal with device-level buffer caching as each 64KB block will contain data for up to 32 different files.

The copying does not create that huge a burden on the system.  Hammer2's biggest performance issue right now has to do with its use of separate threads for compression and transaction handling.

-Matt


----------------------------------------
Bug #3269: Is double-buffer'd buf still required by HAMMER2 ?
http://bugs.dragonflybsd.org/issues/3269#change-14082

* Author: tkusumi
* Status: In Progress
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 6.2
----------------------------------------
This isn't a bug report.
HAMMER2 uses double-buffer'd buf in fs and devvp vnode, which forces strategy routine to memcpy data.

It first appeared in the following commit in 2013, but
"because device buffers can now wind up being a different size"
was changed later on to always use 64KiB, so this no longer applies.

What happens if HAMMER2 uses single-buffer'd buf (like any other non cow fs) in the current code ?


> commit 355d67fcd81e0a7b17007d691bb00bdd151f3d28
> Author: Matthew Dillon <dillon at apollo.backplane.com>
> Date:   Wed Sep 18 19:56:07 2013 -0700
> 
> <snip>
>       My work involved changing the H2 I/O infrastructure to always double-buffer
>       (i.e. logical buffers vs device buffers) because device buffers can now
>       wind up being a different size than the related logical buffers.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account