You can now run `./readbenchfs --mount_point dir --vectored` and then
`dd if=dir/test of=/dev/null iflag=direct bs=1M status=progress` to test
vectored read speed.
My results with GOMAXPROCS=1:
- Before vectored read patch: 390 MB/s read
- Non-vectored read after vectored read patch: 830 MB/s read
- Vectored read: 1200 MB/s read
Read requests can now take vectored responses from the filesystem
implementation and send them to FUSE device via the writev() system call.
This allows file systems to send data without copying it into the
library-provided buffer if the data is already in memory.
The change also speeds up normal ReadFileOps as a side effect because
it removes extra memory allocations.
Closed-source macfuse 4.x has broken compatibility with osxfuse 3.x:
it passes an additional 64-bit field (flags) after RenameIn regardless
that we don't enable the support for RENAME_SWAP/RENAME_EXCL.
The simplest fix is just to check for the presence of all-zero flags
and strip them when they're present.
Co-authored-by: Vitaliy Filippov <vitalif@yourcmc.ru>
Fixes#109. In #102, the storage of the InMessage gets allocated every
time it's being read, which is expensive and caused issues like
https://github.com/GoogleCloudPlatform/gcsfuse/issues/563. So, this
change moves the allocation to its own function, called only once when
the struct is initialized before the reads.
macfuse 4.x turns out to be incompatible with the old mounting method where
you open the device by yourself and only supports the newer method where you
receive a file descriptor from `mount_macfuse` through a unix socket.
Co-authored-by: Vitaliy Filippov <vitalif@yourcmc.ru>
* Bump protocol version to min 7.28, max 7.31
* Increase read/write buffer size to 1MiB
* Add new fields to initOp
* Set FUSE_MAX_PAGES flag for init
* Lower min minor version to 19 for osxfuse
* Fix linux WriteSize test
There's no reason for this to be enforced on the user. For use-cases such as S3-backing, there are no "permissions" of such to base this on. Consequently, everything ends up being owned as root and making it far more difficult to use.
It should, however, be optional.
Expose PID as metadata in CreateFile, OpenFile and FlushFile operations
This will help us with kahing/goofys#273
Co-authored-by: Sai Teja Suram <pratap130492@gmail.com>
Co-authored-by: Sai Teja Suram <pts@avah.dev>
ListXattrOp behaves similarly to GetXattrOp in that you have to
return ERANGE in order to indicate the size of the attribute list,
so logging errors isn't warranted.
when user mount via fstab, we get '-o rw' implicitly, and under
directmount this _enabled_ MS_RDONLY, which is the opposite of what we
want
refs https://github.com/kahing/goofys/issues/483
previously, this will fail if /mnt/file doesn't have an xattr:
```
listxattr("/mnt/file", 0x7fe8b3686830, 256) = -1 EIO (Input/output error)
```
We should be returning the actual size only if the input size is
zero. Related issue is if the filesystem returns ERANGE, we should
propagate that error instead of returning the actual size.
Replaced go-xattr usage with x/sys/unix so we can test this.