Closed DUOLabs333 closed 1 year ago
Create a pull request? Difficult to add comments here.
1) Help text is mission, see opts.c 2) No need for {}, when the if condition has some one line. In fact Radek always puts it into a single line 3) I would add a "," into the last line of the enum, to avoid two line changes when another option is added.
@DUOLabs333 thanks for the patch! ...has it been tested? how?
@aakefbs thanks for your feedback!
@rpodgorny Yes, I'm using it in my own project.
Setting fi->direct_io in open() and create() looks good to me. (As explained in the libfuse issue), the other option is to set it in unionfs_init() with cfg->direct_io=1
@aakefbs I'll push my fork and make a pull request.
See PR #117
However, xbps-install
fails with ERROR: cannot access to pkgdb: No such device
and cannot internalize pkgdb dictionary: No such device
sorry for not responding for a while, i have some catching up to do at work. anyway, i'll be back in action in about two weeks and i plan to merge this.
meanwhile, @DUOLabs333 can you please try to also add some tests? should be pretty simple (see already existing tests). something that tests for both the failing and "fixed" case? ...if not, no problem, i'll add them later myself. (i try to insist on having a test for each new feature, sorry. ;-) )
Well, what do you do with the now failing proc test, if suceeds with fixed kernel? direct-io is like splice and other things a pretty much kernel-module internal thing - there is no straight definition how it acts on it. The proposed use case is here in my opinion a bug on the page cache reading side - instead of using inode stat information after read fails, it does it before. That behavior is totally wrong in a network environment.
Well, what do you do with the now failing proc test, if suceeds with fixed kernel? direct-io is like splice and other things a pretty much kernel-module internal thing - there is no straight definition how it acts on it. The proposed use case is here in my opinion a bug on the page cache reading side - instead of using inode stat information after read fails, it does it before. That behavior is totally wrong in a network environment.
yes, that's exactly why i want a counter-example. once your work gets merged to the kernel module and the "failing" tests starts to not fail, i'll be considering removing the workaround from unionfs. in other words, if there's a workaround for a kernel module bug that fixes things for someone (@DUOLabs333), i'm willing to merge it and remove later in hopes of widening the unionfs' user base.
...or did i get the whole thing wrong?
anyway, the direct_io is a fuse-supported option and i think we should just support it.
I wouldn't remove this option when the test starts to succeed. Some people might just want to use it for something like reducing memory usage - like embedded system short of memory? To be honest, I don't get why the -odirect_io option was removed from libfuse in the first place. The commit message said that it removed file system specific settings, but in the end these were mostly fuse-kernel-module internal settings (splice was also in there, which we should not enabled in unionfs - another option I wouldn't like write a unit test for - it 'just' speeds up large IO). Funny part is that libfuse-3 actually enabled read-splice by default and slows down small IO (<16kb) quite a bit with that, while write-splice doesn't have side effects to my knowledge.
@rpodgorny any reason not to just merge this in?
@rpodgorny any reason not to just merge this in?
...i was just hoping for some tests to be made to actually verify it does something... ...but i'll merge this next week, anyway, even without the tests...
This is a pure setting for the kernel - except of bugs (and unsupported features (mmap MAP_SHARED), it does not make a difference. And so testing might easily give different results. What you actually want to have is a fuse ioctl to get the activated configuration - it does not exists. I still find it very debatable that the direct-io option was removed from libfuse3.
so, i've just created the "directio" branch with the proposed changes. @aakefbs @DUOLabs333 feel free to comment/test - i'll merge it in few days...
i've just released v3.3 with this included. thank you for your contribution and sorry for the long wait!