Is double-buffer'd buf still required by HAMMER2 ?
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 ?
Author: Matthew Dillon <email@example.com>
Date: Wed Sep 18 19:56:07 2013 -0700
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 about 1 month 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.