chore: merge upstream master (0.43.7) into dev, bump to 0.43.7-dc.3#5
Open
alexsavio wants to merge 35 commits into
Open
chore: merge upstream master (0.43.7) into dev, bump to 0.43.7-dc.3#5alexsavio wants to merge 35 commits into
alexsavio wants to merge 35 commits into
Conversation
readdirplus do not increase nlookup for . and .. so we do not increace refcnt for dh.inode and dh.parent
The partRange method incorrectly handled the upper boundary (10000 parts), causing a panic during large multipart uploads. Adjusted the logic to properly process the maximum allowed parts. Fixes yandex-cloud#148
…ading data from a server
<bugfix> fix inode refcnt
…ltipart-parts Fix panic in partRange when uploading exactly 10000 parts
Initialize inode.userMetadata in fillXattr() when a dir is marked implicit (HeadObject 404). This avoids “assignment to entry in nil map” in setUserMeta/SetAttributes.
Prevent panic when setting user metadata on implicit directories
feat: convert hardlink -> symlink
ignore tests tmp files
Add flag to ignore root directory attribute errors
Fix infinite retry loop on read errors
Resolved conflicts: - core/cfg/flags.go: GEESEFS_VERSION -> 0.43.7-dc.3 - core/file.go completeMultipart: adopt upstream numParts() helper (adds maxParts panic guard) while retaining the Dectris copyUnmodifiedParts(numParts, finalSize) source-size hardening; finalSize stays the function parameter, not inode.Attributes.Size.
Reproduces the Feb 2026 fsync InvalidArgument bug where copyUnmodifiedParts issued UploadPartCopy ranges past the source object size, returning: Failed to copy unmodified range ... InvalidArgument: Range specified is not valid for source object of size fuseops.SyncFileOp error: invalid argument Shrinks --part-sizes to 5:20,25:10 so the unaligned-final-part code path is exercised in seconds with files of 27/52/103/127 MiB instead of the original ~21 GB workload. Each case writes via fio, partially overwrites the middle via dd, fsyncs, then the test greps the geesefs container log for the bug markers and fails if any appear. Currently passes against the merged 0.43.7 + Dectris source-size hardening; regression guard going forward.
- mem_limit 256m + --memory-limit 32 + --max-flushers 4 + --max-parallel-parts 8 forces parts to flush mid-stream instead of buffering whole file. - New pattern B: write+fsync, restart geesefs (drops local cache, forces re-open from S3), partial-overwrite middle, fsync. The second fsync is the path that should issue UploadPartCopy from the previously completed S3 object - exact code path of the original bug. - abort_if_dead guard surfaces OOMKilled container instead of cascading failures. 7/7 patterns pass against merged 0.43.7 + Dectris source-size cap; boundary errors absent in geesefs log. Bug does not reproduce under these conditions at small scale.
Pre-fix code hangs the dd oflag=dsync step after the second flush corrupts the multipart upload state, blocking the rest of the test suite. Wrapping fio with 'timeout 90' and dd with 'timeout 60' lets subsequent patterns still run; the per-step size mismatch + log grep still catch the bug. Validated against yandex v0.43.6 (pre PR yandex-cloud#177): bug reproduces with 'Failed to copy unmodified range ... not satisfiable' in the geesefs log and file sizes truncated to 117571584 bytes instead of the requested 147 / 223 MiB. Against the merged 0.43.7 + Dectris source-size cap on this branch: 7/7 pass, clean log.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
master(yandex-cloud 0.43.7, +31 commits) intodev.GEESEFS_VERSION0.43.0-dc.2→0.43.7-dc.3.core/file.go completeMultipart: adopt upstreamnumParts()helper (addsmaxPartspanic guard) while retaining the DectriscopyUnmodifiedParts(numParts, finalSize)source-size hardening;finalSizestays the function parameter, notinode.Attributes.Size.Static build green,
go vet ./core/...clean, S3-free suites + DectrisTestDeepCopypass. Docker integration suite (cd docker && just test-all, MinIO) passing.