Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FUSE passthrough #1336

Open
jaimedelano opened this issue May 12, 2024 · 3 comments
Open

FUSE passthrough #1336

jaimedelano opened this issue May 12, 2024 · 3 comments

Comments

@jaimedelano
Copy link

FUSE passthrough is included in kernel 6.9
How will this affect MergerFS? Is it compatible with the current version of MergerFS?
Do I need to change any settings?

@trapexit
Copy link
Owner

It doesn't affect it. No, existing versions can't use it. Passthough isn't some automatic thing. It is a very specific feature which requires some invasive changes to use. Changes that inherently conflict with certain aspects of how mergerfs works and what it does.

I've spent considerable time prototyping with the feature but due to the complexity haven't anything ready for production. Once I get time I will look into it again but the reality is this feature, as it exists now, is not 100 percent ready for prime time.

@jaimedelano
Copy link
Author

Thank you for clarifying.
I will try /usr/lib/mergerfs/preload.so
What features besides moveonenospc will no longer work?
Current flags I'm using:
noatime,cache.files=off,async_read=false,threads=16,security_capability=false,readahead=1024,cache.readdir=true,func.readdir=cor,posix_acl=true,parallel-direct-writes=true,ignorepponrename=true,category.create=pfrd,category.action=ff,category.search=ff,minfreespace=40G

@trapexit
Copy link
Owner

Anything that has logic while reading or writing. moveonenospc is the most obvious. I honestly can't recall if I ever put the read failover feature in but that would no longer work. The feature is a full passthrough of IO so anything that happens after it is handed over wrt read or write is outside mergerfs' control. Including errors. Also the ability to open different files at the same name across branches would no longer be possible. This is used by some people to improve throughput. Say you make the open policy be "rand". That can't work. This is why the implementation is a pain. mergerfs really doesn't keep track of per node concerns. Only per opened file. But passthrough is a node feature. Not a file opened feature. So I have to ensure that if you opened a file with passthrough it must check if it is already opened and return the same details. It can't open a different file and make that passthrough. It would error. So now I have to keep track of every open file centrally in a way I simply don't right now. Additionally, because passthrough restricts this feature to root only I have to do a bunch of ugly stuff to open the file as the user and then become root to tell the kernel and then jump back to user to do the rest. Also because mergerfs runs as root when doing things as the user it can't read the existing file list from the kernel from its own process which complicates ensuring that it opens the same exact file again. I can't do the normal routine I have to keep the file path, try to open it as the user, and then confirm via another syscall that it is the same file opened elsewhere. It really is a mess.

Your settings would not work with passthrough. Passthrough requires page caching. Passthrough and direct-io (caching = off) can work at the same time but for most users there is no point in that. You probably enable it for performance reasons anyway to it wouldn't be a big deal to change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants