mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 13:26:00 +03:00
[GH-ISSUE #1159] Switch to fuse 3.x #609
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#609
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Keruspe on GitHub (Sep 25, 2019).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1159
From the release notes of libfuse 2.9.9:
@gaul commented on GitHub (Sep 25, 2019):
Can you share what advantages this would provide? While CentOS 7 EPEL includes fuse3, only Ubuntu 19.04 includes fuse3 which means that both 16.04 and 18.04 LTS users would not be able to use s3fs with fuse3.
@juliogonzalez commented on GitHub (Sep 25, 2019):
Would break also CentOS6/RHEL6 (there are no official packages neither at CentOS6/RHEL6 or EPEL, I maintain it unofficially with s3fs 2.8.5, but not sure how complicated would be creating RPMs for 3.x and CentOS6/RHEL6)
It would also break other places with official packages:
All maintained Fedora versions seem to be have already 3.X
@Keruspe commented on GitHub (Sep 25, 2019):
Most obvious advantage would be to depend on a maintained version of fuse instead of a soon-to-be-deprecated one
@gaul commented on GitHub (Sep 25, 2019):
If there are no functional benefits then I do not see a reason to pursue this. After Ubuntu 18.04 ends support in 2023 we can re-evaluate this.
@juliogonzalez commented on GitHub (Sep 25, 2019):
As far as I can see at
configure.ac, s3fs-fuse requires fuse2.8.4as minimum@Keruspe does master compile and work with
3.x?If it does, then there's nothing to do at this moment.
If it doesn't, then it's not critical, but at some point (most probably before 2023), this should be addressed, as I am pretty sure newer distributions will start deprecating removing
2.x, while older distributions will keep it.@ggtakec commented on GitHub (Sep 29, 2019):
@Keruspe Changes from libfuse 2.x to 3.x include the addition of arguments to some I / F functions.
Therefore, it involves a modification of the s3fs code.
I want these source codes to be compatible with each other (not #ifdef), and to make s3fs source code be one codes.
We will make s3fs correspond to libfuse 3.x, but please take some time including testing and investigation.
Thanks in advance for your kindness.
@gaul commented on GitHub (Oct 12, 2020):
It appears that FUSE 3.6.0 supports 1 MB writes:
https://github.com/libfuse/libfuse/blob/master/ChangeLog.rst#libfuse-360-2019-06-13
Previously s3fs saw a large benefit when moving from 4 KB to 128 KB writes #813.
@gaul commented on GitHub (Jan 29, 2022):
I have done as much as I can do with #1867 -- modern Linux is ready for FUSE 3. I don't use macOS and don't understand its FUSE situation but this seems like the biggest blocker. I would appreciate help from the community.
@ggtakec commented on GitHub (Feb 6, 2022):
I think it is possible to support both FUSE2 and FUSE3 with the same source code(using ifdef etc.).
This is a suggestion, but is it possible to separate the packages and support them?(It's not a good name, but s3fs-fuse3, etc.)
If the source code can support both, I think it can only be a matter of how to use the provided package.
Thus, is it possible to omit this issue blocker by suspending the provision of the FUSE3 package on an OS that is difficult to implement?
@breisig commented on GitHub (Jun 15, 2022):
This is a HUGE blocker as most newer distros have moved to FUSE3. I tried compiling the latest version from git and it's still cannot compile against fuse3.
@gaul commented on GitHub (Jun 19, 2022):
@breisig Which Linux distribution does not provide FUSE2?
@jrandall commented on GitHub (Dec 8, 2022):
This is also an issue for singularity --fusemount support, which only works with filesystems built with libfuse3:
(from https://docs.sylabs.io/guides/3.6/user-guide/bind_paths_and_mounts.html#fuse-mounts)
s3fs-fuse does not currently work with singularity because of this.
I believe the reason that fuse 3 is required is that they are using functionality added in libfuse 3.3.0 that allows a privileged process (such as singularity) to mount
/dev/fuseand then pass it as a special file descriptor to the filesystem (in place of a mount point): https://github.com/libfuse/libfuse/blob/master/ChangeLog.rst#libfuse-330-2018-11-06@ggtakec commented on GitHub (Jan 15, 2023):
@jrandall
I am interested in the following features:
https://github.com/libfuse/libfuse/blob/master/ChangeLog.rst#libfuse-330-2018-11-06
And I think it affects #1246 as well.
This issue is closed, but we will continue to consider support for FUSE3.
I have other work to do, so I can't do it right away, but I'm going to proceed with the investigation.
Thank you for your valuable opinion.
@adamqqqplay commented on GitHub (May 6, 2023):
@gaul Yeah, we are also very interested in this feature, it should improve the performance of sequential IO scenarios.
@gaul commented on GitHub (May 27, 2023):
The current macOS FUSE situation is confusing but I don't believe it supports FUSE 3 yet: https://github.com/osxfuse/osxfuse/issues/390
@gaul commented on GitHub (Sep 14, 2023):
Newer FUSE 3 support file birth/creation time: https://www.phoronix.com/news/Linux-6.6-FUSE
@ggtakec commented on GitHub (Jul 14, 2024):
This needs further investigation, but from what I've seen before, the differences between fuse2 and fuse3 interface can be supported with the same source code.
About interface, I beleive that s3fs has
pseudo fdprepared internally, and by making good use of this, I think the differences between fuse2 and fuse3 can be reduced.And I think it looks like statsx support can be added to the existing stat information. (FUSE_DIRECT_IO_RELAX has not been confirmed.)
However, this will require the introduction of a few
ifdef, or dynamic loading of the fuse library.@gaul commented on GitHub (Jul 14, 2024):
I don't think s3fs should take on FUSE2+FUSE3 complexity since all the supported Linux distributions support FUSE3. If the FUSE3 complexity is small, then FUSE-T should make small changes to support their users to enable FUSE3. If it is large then I don't think it is worth our effort. FUSE2 has not had a release since 2008!
@ggtakec commented on GitHub (Jul 15, 2024):
Thank you. This was something I hadn't checked properly.
If there are no problems with installing FUSE3 on each distribution, I don't think there is any need to keep FUSE2 compatibility in s3fs.
@juliogonzalez commented on GitHub (Oct 27, 2024):
About this, not saying this should not be done, but be aware CentOS7 is not the only OS that will go away (CentOS7 should not matter much as it's EoL, even if some clones are not).
Some other OS without FUSE3 (at least not as an official package):
FUSE3 is available in Universe, but remember universe is not supported, although is a workaround.
Of course for RPMs providing FUSE3 could be an alternative to be considered if needed and if it's not too complicated
Every other recent distribution I could check has FUSE3, namely:
So in short, the bump to FUSE3 can be done, but if done before summer 2025, I'd recommend mentioning at the release note the OS that won't be supported.
Related issues: https://github.com/s3fs-fuse/s3fs-fuse/issues/2469 and https://github.com/s3fs-fuse/s3fs-fuse/issues/2496
@ggtakec commented on GitHub (Oct 28, 2024):
I think that modifying the code to support FUSE3(as an initial stage) will not be too difficult, and I am ready to get started.
And at that initial stage, I think the code for FUSE3 and FUSE2 will be able to coexist.
(I think they can be separated by configure or build flags.)
@gaul
Once I've finished my current work, I'll try preparing the code.
(Basically, it's a change to the interface of the functions registered in FUSE, but that can be handled by using pseudofd.)
@gaul commented on GitHub (Nov 6, 2024):
Debian requests that s3fs moves to FUSE 3: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084409
@rjschwei commented on GitHub (May 7, 2025):
And now there is a bug report for openSUSE as well. https://bugzilla.suse.com/show_bug.cgi?id=1242091
@gaul commented on GitHub (May 8, 2025):
I prefer to just require FUSE 3.0 and drop 2.x support. While supporting both is possible I think packagers can just use an older version.
@andreasstieger commented on GitHub (May 8, 2025):
Correct, the situation in the distributions is that fuse3 is available everywhere, and they are trying to get off fuse 2 altogether.
@gaul commented on GitHub (Nov 25, 2025):
I hope someone can contribute benchmarks for this.