Bug #3269
open
Is double-buffer'd buf still required by HAMMER2 ?
0%
Description
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@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.
Updated by dillon almost 3 years ago
- 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