mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 21:35:58 +03:00
[GH-ISSUE #1354] RHEL 6 (Linux 2.6.32) compatibility #726
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#726
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 @gaul on GitHub (Aug 9, 2020).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1354
Recently a StackOverflow user reported an issue compiling s3fs using RHEL 6:
https://stackoverflow.com/questions/63303833/problem-installing-s3fs-on-the-rhel-6-system
This is due to the use of
SEEK_HOLEandSEEK_DATAinPageList::GetSparseFilePages. Linux 3.8 introduced these for ext4. It appears that this works on macOS, at least modern versions.s3fs support for RHEL 6 has always been complicated due its use of an older FUSE. I don't think that we should do anything to support such an ancient distribution since users can compile an older version like 1.86, but I would like this to be an intentional change instead of accidental. Setting a minimum requirement of RHEL 7 and Ubuntu 16.04 (or equivalent) allows s3fs freedom to modernize its dependencies, e.g., C++11, AWS SDK (#1068).
@juliogonzalez commented on GitHub (Aug 9, 2020):
Just a side note: RHEL 6 is on Maintenace Phase until November 30, 2020: https://access.redhat.com/articles/4665701
From that point the Extended Life Phase applies, and that means (https://access.redhat.com/support/policy/updates/errata#Extended_Life_Cycle_Phase): "Red Hat will provide limited ongoing technical support. No bug fixes, security fixes, hardware enablement or root-cause analysis will be available during this phase, and support will be provided on existing installations only." This is not the real EoL, but it's close to it.
CentOS6 goes EoL on November 30, 2020 as well: https://wiki.centos.org/About/Product
In short: documenting that RHEL6/CentOS6 are not supported should be fine, specially because I understand that 1.87 will still support it.
I suggest that a note is added on 1.87 release notes. Something like "WARNING: This is the last s3fs release supporting RHEL6/CentOS6 and Ubuntu <= 16.04). Please consider migrating to a newer OS."
I also suggest you consider the impact on other distributions when bumping dependencies, such as Debian or SLE (AFAIK both provide gcc with C+11 support, but that's to be checked).
In the end it's a matter of finding a balance, as using an old s3fs version can be a problem (since older versions do not have maintenance).
@gaul commented on GitHub (Aug 9, 2020):
Small correction, 1.86 was the last release that compiled on RHEL 6. I would certainly merge a PR which provides a workaround for older Linux distributions but I cannot justify spending my own time to work on this. Managing the backlog of issues for more modern environments is a large enough task already!
@juliogonzalez commented on GitHub (Aug 9, 2020):
Ok, so I understand that master does not build on RHEL6/CentOS6 anymore, is that right?
That's not the end of the world. As a I said, RHEL6/CentOS6 is going EoL soon and the good thing is that because of the fuse dependency, I don't provide official RPMs on EPEL (but I still allow building it from my personal repository, together with the fuse RPMs):
A note on 1.87 stating that RHEL6/CentOS6 is not supported anymore should be fine. I'd also add a note about old Ubuntu versions or any other old distributions known to fail when building. Only reason for this is that it will save github issues created by users, or if they get created they can be closed as invalid, pointing to the doc and/or the release notes.
If you want, I can setup an OBS project to build s3fs master branch for a lot of "alive" distributions, so we can check quickly what builds and what not. Just let me know.
@ggtakec commented on GitHub (Aug 10, 2020):
I understand that it doesn't support RHEL6.
However, I will try building on RHEL6 and code modifications for cases other than the glibc environment.
(But I agree to fade out support for RHEL6.)
@juliogonzalez commented on GitHub (Aug 10, 2020):
Just for completeness, I confirm that master and 1.87 are already broken for RHEL6/CentOS6: https://jenkins.juliogonzalez.es/job/s3fs-fuse-rpm-build-pr/46/DISTRO=centos6,label=docker/console
So with v1.87 I am removing the support for CentOS6/RHEL6 from my repository as well.
Just for your interest, the support for Amazon Linux 1 is not broken, and s3fs v1.87 still compiles even with an old Amazon Linux 2017.03
@juliogonzalez commented on GitHub (Aug 10, 2020):
Wiki updated: https://github.com/s3fs-fuse/s3fs-fuse/wiki/Installation-Notes/_compare/2e1e5a69929771928d35a5ef96d42dd8f4367658
@gaul commented on GitHub (Sep 15, 2020):
@ggtakec Is this fixed?
@ggtakec commented on GitHub (Sep 21, 2020):
Yes, I close this issue.
If we still have problems, reopen this.