On Wed, Jan 20, 2016 at 7:16 PM, Nikhilesh Reddy
<reddyn@xxxxxxxxxxxxxx <mailto:reddyn@xxxxxxxxxxxxxx>> wrote:
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
@@ -569,6 +570,8 @@ ssize_t fuse_simple_request(struct fuse_conn
*fc, struct fuse_args *args)
if (!ret && args->out.argvar) {
BUG_ON(args->out.numargs != 1);
ret = req->out.args[0].size;
+ if (req->passthrough_filp != NULL)
+ args->out.passthrough_filp =
req->passthrough_filp;
}
fuse_put_request(fc, req);
Is it correct to only set passthrough_filp when args->out.argvar is
set here? I tried to test your patch, but I'm still seeing read &
write requests to my FUSE filesystem after setting the passthrough
bit. As far as I can tell, args->out.argvar is only set in a few cases
(like fuse_follow_link()) but not where you're using it in
fuse_create_open() or fuse_send_open(). I changed the logic to this:
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 5cc5385..543c250 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -567,11 +567,14 @@ ssize_t fuse_simple_request(struct fuse_conn
*fc, struct fuse_args *args)
args->out.numargs * sizeof(struct fuse_arg));
fuse_request_send(fc, req);
ret = req->out.h.error;
+ if (!ret) {
+ if (req->passthrough_filp != NULL) {
+ args->out.passthrough_filp =
req->passthrough_filp;
+ }
+ }
if (!ret && args->out.argvar) {
BUG_ON(args->out.numargs != 1);
ret = req->out.args[0].size;
- if (req->passthrough_filp != NULL)
- args->out.passthrough_filp =
req->passthrough_filp;
}
fuse_put_request(fc, req);
And then it worked as expected. The only read() calls I see in my FUSE
filesystem after this change are from mmaped files, but it sounds like
you're already working on that. The performance is much improved for
large reads & writes, so thanks for working on this! I'm excited to
see it finished.
Note that I had to implement the libfuse side of things myself to test
this, so it's possible I'm doing something wrong there to trigger this
behavior. Maybe you could post your libfuse patches somewhere as well?
Then I can make sure I'm testing the same thing that you are.
Thanks,
-Mike