fusefs: per-filehandle direct io

R

Raghav

Hi, I'm new to contributing to FreeBSD and I try to solve issues and learn in the process.

fusefs currently doesn't allows per-filehandle direct io. This was an issue raised by ALAN SOMERS "If a FUSE daemon responds to a FUSE_OPEN request with the FOPEN_DIRECT_IO flag, then it wants the kernel to bypass the cache for that file. And fusefs(4) will honor that. However, the fuse protocol allows a file to be opened multiple times, possibly with different FOPEN_ flags. In that case, the kernel should consider that those FOPEN_ flags reply to one file descriptor only. So whether we bypass the cache should depend on what FUSE_OPEN returned for that particular file descriptor.

The problem is that our current code interprets FOPEN_DIRECT_IO by setting the FN_DIRECTIO flag within the vnode's private data. But there can be multiple file descriptors per vnode. So we can't possibly respect that flag as the protocol intends."

I have made the required changes:
1. fuse_file.c: removed all the code where vnode flag was getting set/unset to FN_DIRECTIO
2. fuse_vnops.c: replaced all the checks of VTOFUD(vp)->flag with checks of
fufh->fuse_open_flags & FOPEN_DIRECTIO. After which I guess fuse_vnop_write and fuse_vnop_read now correctly set IO_DIRECT based on the filehandle not the vnode.

And now i want to write 2 tests one for reads and one for writes. I know that we have to open two file handles whose PIDs are different and the fuse daemon should give FOPEN_DIRECT_IO for one but not for the other. But i dont know how to exactly do it in the gtest framework.

If someone could just guide me for writing the reads test part that would be very helpful.
Thank you.
 
If I was in your situation, I'd write a simple C program that accepts file name, mode, and flags from argc/argv to open a file and issue reads / writes as appropriate. It would also need to sleep for some duration - also based on a parameter before closing. You can run multiple instances with mixed parameters to excercise any manner of concurrent situations. Write a handleful of shell scripts to orchestrate the whole thing.
 
elephant said:
If I was in your situation, I'd write a simple C program that accepts file name, mode, and flags from argc/argv to open a file and issue reads / writes as appropriate. It would also need to sleep for some duration - also based on a parameter before closing. You can run multiple instances with mixed parameters to excercise any manner of concurrent situations. Write a handleful of shell scripts to orchestrate the whole thing.
Click to expand...
Yes maybe I will just write a C program to do that but the test will also be upstreamed along with the fix, it needs to live in /tests/sys/fs/fusefs/read.cc and write.cc and use the existing gtest framework.
 
I don't know the process I'm assuming that the tests will be upstreamed but either way I guess I should start with just a simple program.
Raghav said:
the test will also be upstreamed along with the fix, it needs to live in /tests/sys/fs/fusefs/read.cc and write.cc and use the existing gtest framework.
Click to expand...
 
I am guessing those are unit tests, not integration or stress tests. You could write a coverage test that writes some data, reads it back and compares to was written. There's probably a test like that already.

Oh, I see. It's kyua with gtest underneath. You could do a kyua shell script test.
 
Look at the Makefile in that directory. See the line:

ATF_TESTS_SH+=ctl


Create your own xxx.sh file and add a reference to it like so:

ATF_TESTS_SH+=ctl
ATF_TESTS_SH+=xxx
 
You must log in or register to reply here.
Back
Top