Update eniz1806/vaults3 Docker tag to v4.4.38 #321

2026-07-28T10:03:16+02:00

renovate-bot commented

2026-07-28 10:03:16 +02:00

This PR contains the following updates:

Package	Update	Change
eniz1806/vaults3	patch	`4.4.37` → `4.4.38`

Release Notes

Kodiqa-Solutions/VaultS3 (eniz1806/vaults3)

`v4.4.38`

Compare Source

Fixed

Erasure-coded reads now stream, so GET time-to-first-byte no longer scales with
object size (issue #38, the remaining half). With erasure coding enabled, every
read called io.ReadAll on all shards, ran Reed-Solomon reconstruction, and only
then returned a reader over the finished buffer, so the whole object had to be read
and reassembled before the first byte went out and TTFB grew with size (~3 ms/MiB on
a slower disk, ~200 ms for 64 MiB). Because the code is systematic Reed-Solomon, an
intact object is exactly the concatenation of its data shards, so reads now stream
those shards in order and skip parity math entirely on the healthy path. Measured in
a 3-node cluster with erasure coding (4+2) and incompressible data, TTFB went from
8.2/20.8/39.6 ms at 8/32/64 MiB (scaling, ~0.56 ms/MiB) to a flat ~2.5 ms at every
size, and full-object throughput improved from 258 to 309 MiB/s. Correctness is
unchanged: if a data shard is missing or unreadable the read transparently falls back
to full parity reconstruction, including mid-stream, and Range/partNumber reads
seek directly to the right shard instead of materializing the object. Objects written
by earlier versions read back byte-identical (the on-disk format did not change).
Note that cross-shard parity verification no longer runs on every healthy read (it
would require reading every shard, which is the cost being removed); the background
healer remains responsible for detecting and repairing degraded objects.
Whole-object encryption (SSE-S3/SSE-KMS/per-bucket) still buffers on read to verify
the GCM tag before releasing plaintext, which is tracked separately.

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate.

This PR contains the following updates: | Package | Update | Change | |---|---|---| | [eniz1806/vaults3](https://github.com/Kodiqa-Solutions/VaultS3) | patch | `4.4.37` → `4.4.38` | --- ### Release Notes <details> <summary>Kodiqa-Solutions/VaultS3 (eniz1806/vaults3)</summary> ### [`v4.4.38`](https://github.com/Kodiqa-Solutions/VaultS3/blob/HEAD/CHANGELOG.md#4438---2026-07-27) [Compare Source](https://github.com/Kodiqa-Solutions/VaultS3/compare/v4.4.37...v4.4.38) ##### Fixed - **Erasure-coded reads now stream, so GET time-to-first-byte no longer scales with object size** (issue [#38](https://github.com/Kodiqa-Solutions/VaultS3/issues/38), the remaining half). With erasure coding enabled, every read called `io.ReadAll` on *all* shards, ran Reed-Solomon reconstruction, and only then returned a reader over the finished buffer, so the whole object had to be read and reassembled before the first byte went out and TTFB grew with size (\~3 ms/MiB on a slower disk, \~200 ms for 64 MiB). Because the code is systematic Reed-Solomon, an intact object is exactly the concatenation of its data shards, so reads now stream those shards in order and skip parity math entirely on the healthy path. Measured in a 3-node cluster with erasure coding (4+2) and incompressible data, TTFB went from 8.2/20.8/39.6 ms at 8/32/64 MiB (scaling, \~0.56 ms/MiB) to a flat \~2.5 ms at every size, and full-object throughput improved from 258 to 309 MiB/s. Correctness is unchanged: if a data shard is missing or unreadable the read transparently falls back to full parity reconstruction, including mid-stream, and `Range`/`partNumber` reads seek directly to the right shard instead of materializing the object. Objects written by earlier versions read back byte-identical (the on-disk format did not change). Note that cross-shard parity verification no longer runs on every healthy read (it would require reading every shard, which is the cost being removed); the background healer remains responsible for detecting and repairing degraded objects. Whole-object encryption (SSE-S3/SSE-KMS/per-bucket) still buffers on read to verify the GCM tag before releasing plaintext, which is tracked separately. </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate).

renovate-bot added 1 commit 2026-07-28 10:03:16 +02:00

Update eniz1806/vaults3 Docker tag to v4.4.38 f3490b22a5

renovate-bot scheduled this pull request to auto merge when all checks succeed 2026-07-28 10:03:17 +02:00

renovate-bot merged commit b30e9af10b into main

2026-07-28 10:03:19 +02:00

renovate-bot deleted branch renovate/eniz1806-vaults3-4.x

2026-07-28 10:03:20 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: arnoutvw/compose-files#321