starred/s3fs-fuse
1
0
Fork 0
mirror of https://github.com/s3fs-fuse/s3fs-fuse.git synced 2026-04-25 13:26:00 +03:00
Code Issues 305 Projects Releases 5 Packages Wiki Activity

[GH-ISSUE #1050] 1.86 release #578

New issue
Closed
opened 2026-03-04 01:46:53 +03:00 by kerem · 17 comments
kerem commented 2026-03-04 01:46:53 +03:00
Owner
Copy link

Originally created by @gaul on GitHub (Jun 24, 2019).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1050

master has a number of changes since 1.85, some in-progress pull requests, and a few issues that I am investigating:

  • Time problem with large files #1019 (regression from 1.84)
  • file corruption with use_cache and external modifications #1047
  • git clone premature end of pack file #839
  • The upload element blocking subsequent transfers #928
Originally created by @gaul on GitHub (Jun 24, 2019). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1050 master has a number of [changes since 1.85](https://github.com/s3fs-fuse/s3fs-fuse/compare/v1.85...master), some in-progress pull requests, and a few issues that I am investigating: - [x] Time problem with large files #1019 (regression from 1.84) - [x] file corruption with `use_cache` and external modifications #1047 - [x] `git clone` premature end of pack file #839 - [x] The upload element blocking subsequent transfers #928
kerem closed this issue 2026-03-04 01:46:54 +03:00
kerem commented 2026-03-04 01:46:54 +03:00
Author
Owner
Copy link

@amolthorat1 commented on GitHub (Jul 17, 2019):

Hello,

Any update on the next release date for s3fs?

Thanks.

<!-- gh-comment-id:512227167 --> @amolthorat1 commented on GitHub (Jul 17, 2019): Hello, Any update on the next release date for s3fs? Thanks.
kerem commented 2026-03-04 01:46:54 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Jul 17, 2019):

@amolthorat1 I want to add # 1098 in addition to the contents suggested by @gaul.
Since some correspondence still remains now, please wait a little more.

<!-- gh-comment-id:512252138 --> @ggtakec commented on GitHub (Jul 17, 2019): @amolthorat1 I want to add # 1098 in addition to the contents suggested by @gaul. Since some correspondence still remains now, please wait a little more.
kerem commented 2026-03-04 01:46:54 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Jul 17, 2019):

You do not need to wait for a release version; just git clone the repository to get the latest fixes.

<!-- gh-comment-id:512350687 --> @gaul commented on GitHub (Jul 17, 2019): You do not need to wait for a release version; just `git clone` the repository to get the latest fixes.
kerem commented 2026-03-04 01:46:55 +03:00
Author
Owner
Copy link

@amolthorat1 commented on GitHub (Jul 18, 2019):

We need to be able to point customer to a release version - getting the source code and building it may not work for them.

<!-- gh-comment-id:512791169 --> @amolthorat1 commented on GitHub (Jul 18, 2019): We need to be able to point customer to a release version - getting the source code and building it may not work for them.
kerem commented 2026-03-04 01:46:55 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Jul 19, 2019):

s3fs will release when it is ready. I suggest you fork the repo and tag a version for your customer.

<!-- gh-comment-id:513044049 --> @gaul commented on GitHub (Jul 19, 2019): s3fs will release when it is ready. I suggest you fork the repo and tag a version for your customer.
kerem commented 2026-03-04 01:46:55 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Jul 31, 2019):

@ggtakec Fedora 31 and Ubuntu 19.10 both release in October and it would be nice if they could include the many bug fixes since 1.85. Could we merge #1066 and #1107 and tag 1.86? I worry that delaying the release for #1098 poses too much risk. I can handle the release process if this helps.

<!-- gh-comment-id:516703345 --> @gaul commented on GitHub (Jul 31, 2019): @ggtakec Fedora 31 and Ubuntu 19.10 both release in October and it would be nice if they could include the many bug fixes since 1.85. Could we merge #1066 and #1107 and tag 1.86? I worry that delaying the release for #1098 poses too much risk. I can handle the release process if this helps.
kerem commented 2026-03-04 01:46:55 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Jan 13, 2020):

@ggtakec I would like to release 1.86 in the hope that Ubuntu 20.04 LTS can include it. Would you mind if I tagged the current master and wrote the release notes? For the latter I would like to follow a simpler, user-focused format since GitHub already provides the commit list between versions. I drafted this:

  • add intelligent_ia storage tier
  • add requester_pays support
  • add session token support
  • add symlink cache
  • allow concurrent metadata queries during data operations
  • allow large files on 32-bit systems like Raspberry Pi
  • allow SSE-C keys to have NUL bytes
  • enable various optimizations when using modern curl
  • fix clock skew errors when writing large files
  • fix data corruption when external modification changes a cached object
  • fix data corruption when opening a second fd to an unflushed file
  • fix multiple concurrency issues
  • use server-side copy for partially modified files
<!-- gh-comment-id:573620345 --> @gaul commented on GitHub (Jan 13, 2020): @ggtakec I would like to release 1.86 in the hope that Ubuntu 20.04 LTS can include it. Would you mind if I tagged the current master and wrote the release notes? For the latter I would like to follow a simpler, user-focused format since GitHub already provides the commit list between versions. I drafted this: * add intelligent_ia storage tier * add requester_pays support * add session token support * add symlink cache * allow concurrent metadata queries during data operations * allow large files on 32-bit systems like Raspberry Pi * allow SSE-C keys to have NUL bytes * enable various optimizations when using modern curl * fix clock skew errors when writing large files * fix data corruption when external modification changes a cached object * fix data corruption when opening a second fd to an unflushed file * fix multiple concurrency issues * use server-side copy for partially modified files
kerem commented 2026-03-04 01:46:55 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Jan 24, 2020):

@gaul I suppose that your description is okay, but ChangeLog and ReleaseNotes should match the old ChangeLog format.

#<PR ID> <Title>

I think that you can add your description(text) to Release tag page as outline.

However, I would like to complete #1151 if possible.
We believe that only the test results in an error, so we can handle it.
I want to investigate the cause as soon as possible.

Sorry to keep you waiting

<!-- gh-comment-id:578153133 --> @ggtakec commented on GitHub (Jan 24, 2020): @gaul I suppose that your description is okay, but ChangeLog and ReleaseNotes should match the old ChangeLog format. ``` #<PR ID> <Title> ``` I think that you can add your description(text) to Release tag page as outline. However, I would like to complete #1151 if possible. We believe that only the test results in an error, so we can handle it. I want to investigate the cause as soon as possible. Sorry to keep you waiting
kerem commented 2026-03-04 01:46:55 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Jan 26, 2020):

Agreed that linking to the PRs is a good idea. However, I have concerns about waiting for one more PR. I would really like Ubuntu 20.04 to include s3fs 1.86 since it has several data corruption fixes. This release is LTS which will be supported for 5 years likely without s3fs upgrades:

https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule

I don't know if it is too late to include it already but Ubuntu recently upgraded to 1.85:

https://bugs.launchpad.net/ubuntu/+source/s3fs-fuse/+bug/1828849

<!-- gh-comment-id:578482054 --> @gaul commented on GitHub (Jan 26, 2020): Agreed that linking to the PRs is a good idea. However, I have concerns about waiting for one more PR. I would really like Ubuntu 20.04 to include s3fs 1.86 since it has several data corruption fixes. This release is LTS which will be supported for 5 years likely without s3fs upgrades: https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule I don't know if it is too late to include it already but Ubuntu recently upgraded to 1.85: https://bugs.launchpad.net/ubuntu/+source/s3fs-fuse/+bug/1828849
kerem commented 2026-03-04 01:46:55 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Jan 26, 2020):

@gaul
I will add #1151's comment, but it seems that this PR will take time to resolve.
(I merged one PR as #1230 for fixing test code.)
It seems that several factors are compounded.
I agree that #1151 will carry over to the next version.
(I will continue to investigate)

We are going to release v1.86 with the current code.

<!-- gh-comment-id:578514029 --> @ggtakec commented on GitHub (Jan 26, 2020): @gaul I will add #1151's comment, but it seems that this PR will take time to resolve. (I merged one PR as #1230 for fixing test code.) It seems that several factors are compounded. I agree that #1151 will carry over to the next version. (I will continue to investigate) We are going to release v1.86 with the current code.
kerem commented 2026-03-04 01:46:55 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Jan 28, 2020):

@gaul I merged #1232.
I think this will make the #1151 PR a success.

<!-- gh-comment-id:579209134 --> @ggtakec commented on GitHub (Jan 28, 2020): @gaul I merged #1232. I think this will make the #1151 PR a success.
kerem commented 2026-03-04 01:46:55 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Feb 3, 2020):

I plan to tag the release this week. I am still scrubbing through all the bugs but surfaced a few minor PRs.

<!-- gh-comment-id:581215460 --> @gaul commented on GitHub (Feb 3, 2020): I plan to tag the release this week. I am still scrubbing through all the bugs but surfaced a few minor PRs.
kerem commented 2026-03-04 01:46:55 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Feb 5, 2020):

@gaul I understand the release tag.
(Sorry for my late reply)

<!-- gh-comment-id:582417490 --> @ggtakec commented on GitHub (Feb 5, 2020): @gaul I understand the release tag. (Sorry for my late reply)
kerem commented 2026-03-04 01:46:55 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Feb 5, 2020):

Sorry I already tagged this and requested that Ubuntu upgrade to 1.86:

https://bugs.launchpad.net/ubuntu/+source/s3fs-fuse/+bug/1862023

<!-- gh-comment-id:582418502 --> @gaul commented on GitHub (Feb 5, 2020): Sorry I already tagged this and requested that Ubuntu upgrade to 1.86: https://bugs.launchpad.net/ubuntu/+source/s3fs-fuse/+bug/1862023
kerem commented 2026-03-04 01:46:55 +03:00
Author
Owner
Copy link

@juliogonzalez commented on GitHub (Feb 5, 2020):

Starting submissions for openSUSE (devel project), Fedora and EPEL.

<!-- gh-comment-id:582623726 --> @juliogonzalez commented on GitHub (Feb 5, 2020): Starting submissions for openSUSE (devel project), Fedora and EPEL.
kerem commented 2026-03-04 01:46:55 +03:00
Author
Owner
Copy link

@juliogonzalez commented on GitHub (Feb 5, 2020):

For reference:

OpenSUSE (devel project): https://build.opensuse.org/request/show/770406 (will reach Tumbleweed, and hopefully Leap 15.2)
Fedora Rawhide & 32 (koji build): https://koji.fedoraproject.org/koji/taskinfo?taskID=41399105
EPEL8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3d094c3f20
EPEL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d4cebca350
Fedora31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d183c526b4
Fedora30: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8d0d2ef18c

For EPEL8/7 and Fedora31/30: Remember that the updates are time based (14 days) or karma based (3 positive feedback each). So if someone is testing the updates, remember to provide karma (of course, negative as well if something is not right).

NOTE: I submitted the new version to EPEL8/7 and Fedora30/31 as:

  • It is a minor release
  • It includes mostly bugfixing, but with IMPORTANT bugfixes
  • The update doesn't affect user experience

So IMHO we are inline with https://fedoraproject.org/wiki/Updates_Policy#All_other_updates

But to be honest, I am tempted to follow:

Package maintainers SHOULD:
Push only major bug fixes and security fixes to the previous stable releases (i.e., at present, Fedora 30 and before).

From the doc above, and only update the package in the future if there are bugs reported at Fedora's bugzilla (basically that's the policy for openSUSE Leap, but there we'd need to provide individual patches, and not version updates, pretty much as Debian/Ubuntu).

Are we currently redirecting EPEL/Fedora users there when they report failures and they are using the official packages?

<!-- gh-comment-id:582661884 --> @juliogonzalez commented on GitHub (Feb 5, 2020): For reference: OpenSUSE (devel project): https://build.opensuse.org/request/show/770406 (will reach Tumbleweed, and hopefully Leap 15.2) Fedora Rawhide & 32 (koji build): https://koji.fedoraproject.org/koji/taskinfo?taskID=41399105 EPEL8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3d094c3f20 EPEL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d4cebca350 Fedora31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d183c526b4 Fedora30: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8d0d2ef18c For EPEL8/7 and Fedora31/30: Remember that the updates are time based (14 days) or karma based (3 positive feedback each). So if someone is testing the updates, remember to provide karma (of course, negative as well if something is not right). NOTE: I submitted the new version to EPEL8/7 and Fedora30/31 as: - It is a minor release - It includes mostly bugfixing, but with IMPORTANT bugfixes - The update doesn't affect user experience So IMHO we are inline with https://fedoraproject.org/wiki/Updates_Policy#All_other_updates But to be honest, I am tempted to follow: > Package maintainers SHOULD: > Push only major bug fixes and security fixes to the previous stable releases (i.e., at present, Fedora 30 and before). From the doc above, and only update the package in the future if there are bugs reported at Fedora's bugzilla (basically that's the policy for openSUSE Leap, but there we'd need to provide individual patches, and not version updates, pretty much as Debian/Ubuntu). Are we currently redirecting EPEL/Fedora users there when they report failures and they are using the official packages?
kerem commented 2026-03-04 01:46:56 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Feb 8, 2020):

@juliogonzalez Thanks for packaging this! I submitted positive karma for Fedora 31. Personally Fedora 30 does not interest me but I am glad that EPEL 7 and 8 will include s3fs 1.86 since these will live on for many years. Ideally users would report bugs here since I rarely check distribution issue trackers but I understand that their policies.

<!-- gh-comment-id:583739592 --> @gaul commented on GitHub (Feb 8, 2020): @juliogonzalez Thanks for packaging this! I submitted positive karma for Fedora 31. Personally Fedora 30 does not interest me but I am glad that EPEL 7 and 8 will include s3fs 1.86 since these will live on for many years. Ideally users would report bugs here since I rarely check distribution issue trackers but I understand that their policies.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
v1.97
v1.96
v1.95
v1.94
v1.93
v1.92
v1.91
v1.90
v1.89
v1.88
v1.87
v1.86
v1.85
v1.84
v1.83
v1.82
v1.81
v1.80
v1.79
v1.78
Pre-v1.78
v1.77
v1.76
v1.75
v1.74
Labels
Clear labels   
bug

   
bug

   
dataloss

   
duplicate

   
enhancement

   
feature request

   
help wanted

   
invalid

   
need info

   
performance

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
question

   
testing
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/s3fs-fuse#578
No description provided.