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 <dil...@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

Reply via email to