[mchaarawi]

Point fused at the daos-stack/fused mschaara/fuse-3.18.3 branch for testing: upstream libfuse 3.18.3 renamed to fused, versioned 1.2.0, with the fusermount3 launch kept as fork+exec instead of posix_spawn, which does not work under valgrind. Bump the fused-devel package version so CI builds fused from source instead of installing 1.0.0.

Features: dfuse pil4dfs

Steps for the author:

• Commit message follows the guidelines.
• Appropriate Features or Test-tag pragmas were used.
• Appropriate Functional Test Stages were run.
• At least two positive code reviews including at least one code owner from each category referenced in the PR.
• Testing is complete. If necessary, forced-landing label added and a reason added in a comment.

After all prior steps are complete:

• Gatekeeper requested (daos-gatekeeper added as a reviewer).

[github-actions]

Ticket title is 'update fused to latest libfuse release'
Status is 'Open'
https://daosio.atlassian.net/browse/DAOS-19915

[daosbuild3]

Test stage Unit Test completed with status UNSTABLE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net/job/daos-stack/job/daos//view/change-requests/job/PR-19417/2/testReport/

[ifnotcode]

Hi @mchaarawi, thanks for picking up the libfuse 3.18 update. A heads-up on an overlap with #19405.
#19405 bumps fused to 1.1.0 (libfuse 3.17.4) to get FUSE_CAP_ALLOW_IDMAP for #19404. That PR adds a dfuse --allow-idmap option, which is needed for idmapped mounts, e.g. Kubernetes pods with hostUsers: false on Linux >= 6.12.

On 3.18.3 the fuse_kernel.h sync (d393ffa8) is already included, so the only missing piece is a backport of libfuse commit 1f4c0608. That commit is not in any upstream release yet.

Would you be open to adding that one patch, either to the mschaara/fuse-3.18.3 fused branch or to deps/patches/fused in this PR? The capability is only sent to the kernel when a filesystem requests it, so behaviour without --allow-idmap is unchanged. If you agree, I'll close #19405 in favour of this PR.

One packaging detail: dfuse guards the option with #ifdef, so a fused-devel 1.2.0 build without the patch would silently drop --allow-idmap. The BuildRequires should point at a fused-devel release that carries the patch.

Test results for the 3.17.4 variant are in #19405: the NLT posix suite with --allow-idmap on every dfuse, and ftest with and without the option. I'm happy to rerun them against 1.2.0.

[mchaarawi]

Hi @mchaarawi, thanks for picking up the libfuse 3.18 update. A heads-up on an overlap with [#19405]. [#19405] bumps fused to 1.1.0 (libfuse 3.17.4) to get FUSE_CAP_ALLOW_IDMAP for [#19404]. That PR adds a dfuse --allow-idmap option, which is needed for idmapped mounts, e.g. Kubernetes pods with hostUsers: false on Linux >= 6.12.

On 3.18.3 the fuse_kernel.h sync (d393ffa8) is already included, so the only missing piece is a backport of libfuse commit 1f4c0608. That commit is not in any upstream release yet.

Would you be open to adding that one patch, either to the mschaara/fuse-3.18.3 fused branch or to deps/patches/fused in this PR? The capability is only sent to the kernel when a filesystem requests it, so behaviour without --allow-idmap is unchanged. If you agree, I'll close [#19405] in favour of this PR.

One packaging detail: dfuse guards the option with #ifdef, so a fused-devel 1.2.0 build without the patch would silently drop --allow-idmap. The BuildRequires should point at a fused-devel release that carries the patch.

Test results for the 3.17.4 variant are in [#19405]: the NLT posix suite with --allow-idmap on every dfuse, and ftest with and without the option. I'm happy to rerun them against 1.2.0.

thank you for you PRs and the heads up. i would like to keep this upgrade independent of your work and your feature request.
what you pushed looks reasonable but requires more review and testing on our side; but first to detrermine a targeted release (3.0 or 3.2). i will need to discuss your feature request with the TSC and our test team to see what is feasible.

[daosbuild3]

Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-19417/3/execution/node/1309/log

[daltonbohning]

Where is this package actually used? It seems we only build fused-devel and at least for 2.8 we don't ship it?
https://packages.daos.io/v2.8.1/EL9/packages/x86_64/

[mchaarawi]

Where is this package actually used? It seems we only build fused-devel and at least for 2.8 we don't ship it? https://packages.daos.io/v2.8.1/EL9/packages/x86_64/

we do not ship the fused RPM. it is statically built

[daosbuild3]

Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-19417/4/execution/node/1814/log