Open asomers opened 3 years ago
use writev
should avoid memory copy, we own the header buffer and user data(such as Filesystem::read
will return Bytes
)
when read fuse request, we can allocate 2 buffer, one for header the other for fuse data, when receive a write opcode, consider
The max size of write requests from the kernel. The absolute minimum is 4k, FUSE recommends at least 128k, max 16M. The FUSE default is 16M on macOS and 128k on other systems.
the data may be large or small
Filesystem::write
, we need to allocate the data buffer(the buffer size is 16M) againFilesystem::write
then we allocate the data buffer again, but this is no different from the status quo.anyway, we can replace read/write with readv/writev at first, then find a way to improve write opcode
BTW, the maximum size of write that a filesystem will receive is given by the max_write
field during FUSE_INIT
. So it could be much less than 16M.
During a write, fuse3 first copies data from the kernel into userland in
Session::dispatch
. Then it passes a slice of that buffer tohandle_write
, which ends up copying the data again into a newVec
. It then passes that data as a slice toFilesystem::write
, where it might well be copied again. The same thing happens insetxattr
.Instead,
Session::dispatch
should read from /dev/fuse usingreadv
into a header-sized buffer and a large data buffer. Then it should pass the data buffer by value toFilesystem::write
using aVec
. That would eliminate one data copy, and possibly two, depending on how the file system implementswrite
.