Skip to content

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
devfrom
chore/merge-master-0.43.7-dc.3
Open

chore: merge upstream master (0.43.7) into dev, bump to 0.43.7-dc.3#5
alexsavio wants to merge 35 commits into
devfrom
chore/merge-master-0.43.7-dc.3

Conversation

@alexsavio
Copy link
Copy Markdown
Collaborator

@alexsavio alexsavio commented May 19, 2026

Summary

  • Merge upstream master (yandex-cloud 0.43.7, +31 commits) into dev.
  • Bump GEESEFS_VERSION 0.43.0-dc.20.43.7-dc.3.
  • Conflict in 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.

Static build green, go vet ./core/... clean, S3-free suites + Dectris TestDeepCopy pass. Docker integration suite (cd docker && just test-all, MinIO) passing.

VVoidV and others added 30 commits April 1, 2025 22:15
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
…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
Add flag to ignore root directory attribute errors
temka-io and others added 5 commits May 5, 2026 14:58
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants