DAOS-14733: Add FUSE_PARALLEL_DIROPS patch #3
Conversation
brianjmurrell
force-pushed
the
bmurrell/update
branch
2 times, most recently
from
2475f9a to
300a850
Compare
Add patch for: https://issues.redhat.com/browse/RHEL-19149 libfuse/libfuse#861 libfuse/libfuse@c990534 Add rpmlintrc exception. Sync with upstream. Update packaging. Update Test-tag to do all dfuse tests. Skip-PR-comments: true Required-githooks: true Signed-off-by: Brian J. Murrell <[email protected]>
Skip-PR-comments: true Required-githooks: true Signed-off-by: Brian J. Murrell <[email protected]>
brianjmurrell
force-pushed
the
bmurrell/update
branch
from
300a850 to
5fb5857
Compare
| outargflags |= FUSE_ASYNC_DIO; | ||
| if (se->conn.want & FUSE_CAP_WRITEBACK_CACHE) | ||
| outargflags |= FUSE_WRITEBACK_CACHE; | ||
| + if (se->conn.want & FUSE_CAP_PARALLEL_DIROPS) |
There was a problem hiding this comment.
There was a follow on patch to the original to disable this by default because it breaks some fuse instances that are not prepared for it. Did we get that patch too? We would not want to break non-dfuse mounts.
There was a problem hiding this comment.
Indeed, I am aware of the follow-on patch. The patch above is really just a placeholder until we get an official RH-blessed backport patch, which is apparently in progress now that the issue that resulted in the patch you refer to has been resolved between RH and the fuse maintainers.
I appreciate the heads-up though.
| @@ -4,7 +4,7 @@ | |||
|
|
|||
There was a problem hiding this comment.
Is there a reason we don't update to a later version and then apply a minimal set of patches? Is this the version on rh? Looks like latest libfuse is 3.16.2
There was a problem hiding this comment.
For context, I'm considering a patch to statically link the libfuse library only. This would allow us to set this to the latest for our build without affecting whatever the system wants to use.
There was a problem hiding this comment.
Obviously, this would require some changes to this repo and some testing of the same. But I tested it locally and it removes the runtime dependence on libfuse3.so and seems to work.
There was a problem hiding this comment.
For context, I'm considering a patch to statically link the libfuse library only.
We definitely don't want to static link. Doing so would require that we do an entire release cycle including all of the manual QA and SDL and whatnot in order to fix a bug [security or otherwise] in the libfuse that we statically link with. With dynamic linking we can release just a fuse update and users can install that to resolve whatever issues there are. Much less overhead on our part.
This would allow us to set this to the latest for our build without affecting whatever the system wants to use.
What other things are you looking to get out of a newer fuse?
There was a problem hiding this comment.
Is there a reason we don't update to a later version and then apply a minimal set of patches?
Because our ultimate goal is to be able to continue to use the package from RH once they patch what we want into it.
Is this the version on rh? Looks like latest libfuse is 3.16.2
Keep in mind that during a release RH prefers to keep their base the same and add patches to address features and bugs so the version marked on a package does not necessarily reflect the features/bugs that have been addressed in it.
Skip-PR-comments: true Required-githooks: true Signed-off-by: Brian J. Murrell <[email protected]>
Skip-PR-comments: true Required-githooks: true Signed-off-by: Brian J. Murrell <[email protected]>
Skip-PR-comments: true Required-githooks: true Signed-off-by: Brian J. Murrell <[email protected]>
Skip-PR-comments: true Required-githooks: true Signed-off-by: Brian J. Murrell <[email protected]>
brianjmurrell
force-pushed
the
master
branch
2 times, most recently
from
ba2967f to
2f5e21b
Compare
Add patch for:
https://issues.redhat.com/browse/RHEL-19149
libfuse/libfuse#861
libfuse/libfuse@c990534