Skip to content

chore(deps): bump xet-core to main (1.6.0) - #244

Open
XciD wants to merge 1 commit into
mainfrom
chore/bump-xet-core
Open

XciD wants to merge 1 commit into
mainfrom
chore/bump-xet-core

Conversation

@XciD

@XciD XciD commented Sep 29, 2026 •

Copy link
Copy Markdown
Member

Moves the pinned xet-core rev from 0e474005 (2026-07-07) to 388c93cc (current main, crates at 1.6.0).

Changes needed in hf-mount

  • Client::upload_shard now takes an optional ShardUploadProgressCallback and returns () (v2 shard upload API, Stream shard finalization progress via POST /v2/shards xet-core#884). CachedXetClient forwards the callback to the inner client.
  • Upload sessions now report transfer telemetry to CAS (POST /v1/telemetry, feat(telemetry): runtime config group and pre-shutdown drain hook xet-core#932 to #937), and finalize() awaits the terminal document for up to 2 s by default. In the default write mode, close() waits for the commit, so every write would pay that round trip. HF_XET_TELEMETRY_FINAL_FLUSH_TIMEOUT=0s sends it detached instead: the daemon outlives the request, so it is still delivered. Measured with this branch on Linux (20 files of 1 KiB, default write mode, bucket in us-east-1): median close() 259 ms with the upstream 2 s budget, 182 ms detached. Telemetry stays on (per xet-core, the payload has no file names, paths, hashes, repo ids or user ids), and the usual opt-outs still apply (HF_HUB_DISABLE_TELEMETRY, DO_NOT_TRACK, HF_XET_TELEMETRY_ENABLED=false). Reads send nothing: download sessions and streams go through CachedXetClient, which keeps the default transfer_telemetry() (None).

Behavior notes

  • Download buffer defaults are now derived from usable memory (Derive download buffer defaults from usable, cgroup-aware system memory xet-core#943). hf-mount already sets HF_XET_RECONSTRUCTION_DOWNLOAD_BUFFER_SIZE and HF_XET_RECONSTRUCTION_DOWNLOAD_BUFFER_LIMIT, so only the per-file increment changes: 512 MB before, usable memory / 64 now (clamped to [16 MB, 2 GB]), still under the 256 MiB limit.
  • Also brings sha2 0.11 and the h2 (RUSTSEC-2026-0258), rustls (RUSTSEC-2026-0285) and der bumps. The TLS backend is unchanged (rustls).

Found while bumping, not changed here

HF_XET_CLIENT_READ_TIMEOUT=30 and HF_XET_RECONSTRUCTION_TARGET_BLOCK_COMPLETION_TIME=30 have never been applied: xet-core parses durations with humantime, which rejects a number without a unit, so it falls back to its defaults (300 s and 15 min). The warning is hidden by the hf_mount=info log filter (seen with RUST_LOG=info on v0.13.1). Writing 30s would activate two settings that never ran, so that belongs in a separate change.

@XciD
XciD marked this pull request as ready for review September 29, 2026 20:45
@github-actions

Copy link
Copy Markdown
Contributor

POSIX Compliance (pjdfstest)

============================================================
  pjdfstest POSIX Compliance Results
------------------------------------------------------------
  Files: 130/130 passed    Tests: 832 total (0 subtests failed)
  Result: PASS
------------------------------------------------------------
  Category               Passed    Total   Status
  -------------------- -------- -------- --------
  chflags                     5        5       OK
  chmod                       8        8       OK
  chown                       6        6       OK
  ftruncate                  13       13       OK
  granular                    5        5       OK
  mkdir                       9        9       OK
  open                       19       19       OK
  posix_fallocate             1        1       OK
  rename                     10       10       OK
  rmdir                      11       11       OK
  symlink                    10       10       OK
  truncate                   13       13       OK
  unlink                     11       11       OK
  utimensat                   9        9       OK
============================================================

@github-actions

github-actions Bot commented Sep 29, 2026 •

Copy link
Copy Markdown
Contributor

Benchmark Results

============================================================
  Benchmark — 50MB
------------------------------------------------------------
  Metric                                 FUSE          NFS
  ------------------------------ ------------ ------------
  Sequential read                    126.1 MB/s     208.8 MB/s
  Sequential re-read                2093.0 MB/s    2489.3 MB/s
  Range read (1MB@25MB)                0.2 ms         0.2 ms
  Random reads (100x4KB avg)           0.0 ms         0.0 ms
  Sequential write (FUSE)           1475.8 MB/s
  Close latency (CAS+Hub)            0.113 s
  Write end-to-end                   341.4 MB/s
  Dedup write                       1757.7 MB/s
  Dedup close latency                0.094 s
  Dedup end-to-end                   408.3 MB/s
============================================================
============================================================
  Benchmark — 200MB
------------------------------------------------------------
  Metric                                 FUSE          NFS
  ------------------------------ ------------ ------------
  Sequential read                    591.5 MB/s     272.1 MB/s
  Sequential re-read                2085.5 MB/s    2366.3 MB/s
  Range read (1MB@25MB)                0.2 ms         0.2 ms
  Random reads (100x4KB avg)           0.0 ms         0.0 ms
  Sequential write (FUSE)           1589.0 MB/s
  Close latency (CAS+Hub)            0.153 s
  Write end-to-end                   716.9 MB/s
  Dedup write                       1590.3 MB/s
  Dedup close latency                0.105 s
  Dedup end-to-end                   868.0 MB/s
============================================================
============================================================
  Benchmark — 500MB
------------------------------------------------------------
  Metric                                 FUSE          NFS
  ------------------------------ ------------ ------------
  Sequential read                   1140.6 MB/s    1463.6 MB/s
  Sequential re-read                2136.0 MB/s    2362.3 MB/s
  Range read (1MB@25MB)                0.2 ms         0.2 ms
  Random reads (100x4KB avg)           0.0 ms         0.0 ms
  Sequential write (FUSE)           1514.4 MB/s
  Close latency (CAS+Hub)            0.147 s
  Write end-to-end                  1047.6 MB/s
  Dedup write                       1545.6 MB/s
  Dedup close latency                0.101 s
  Dedup end-to-end                  1178.7 MB/s
============================================================
============================================================
  fio Benchmark Results
------------------------------------------------------------
  Job                        FUSE MB/s   NFS MB/s  FUSE IOPS   NFS IOPS
  ------------------------- ---------- ---------- ---------- ----------
  seq-read-100M                  357.1      537.6                      
  seq-reread-100M               2564.1       11.8                      
  rand-read-4k-100M                0.1        0.1         16         20
  seq-read-5x10M                 510.2      909.1                      
  rand-read-10x1M                  0.1        0.1         36         37
  Random Read Latency           FUSE avg      NFS avg
  ------------------------- ------------ ------------
  rand-read-4k-100M           61435.5 us   50117.5 us
  rand-read-10x1M             27681.7 us   26968.5 us
============================================================

XciD added a commit that referenced this pull request Sep 29, 2026
## Problem

xet-core parses durations with humantime, which rejects a bare number.
It then keeps its own default and logs a WARN under `xet_runtime`, which
the default `hf_mount=info` filter hides. Two of the defaults set in
`init_tracing` have therefore never been applied:

- `HF_XET_CLIENT_READ_TIMEOUT=30`: reads ran with the 300 s default
inactivity timeout, not 30 s.
- `HF_XET_RECONSTRUCTION_TARGET_BLOCK_COMPLETION_TIME=30`: prefetch
targeted 15 minutes of transfer, not 30 s.

With `RUST_LOG=info`, v0.13.1 logs `Configuration value 30 for
read_timeout cannot be parsed into correct type; reverting to default.`
(same for `target_block_completion_time`).

## Fix

Both values are now `30s`. The defaults move into `xet_env_defaults()`,
and `xet_env_defaults_are_accepted_by_xet_core` passes each one through
`XetConfig::with_config` for its `HF_XET_<GROUP>_<FIELD>` path. That
rejects a value xet-core cannot parse and a setting it no longer knows
(for example after an upstream rename). On main, the test fails and
lists exactly these two defaults. The other nine pass.

## Effect

With this branch, xet-core logs `read_timeout = 30s (user set)` and
`target_block_completion_time = 30s (user set)`. The prefetch target is
`rate x target_block_completion_time`, bounded by the 256 MiB download
buffer limit, so fast streams see no change and only slow streams
prefetch less. Cold sequential reads of a 3.09 GB xet file
(`Qwen/Qwen2.5-1.5B-Instruct`, `--no-disk-cache`, m6i.2xlarge, 8
alternating runs each) gave a median of 556 MB/s on v0.13.1 and 558 MB/s
with this change, within network noise.

This PR and #244 both touch the xet env defaults list, so whichever
lands second needs a rebase. The new test will then also check
`HF_XET_TELEMETRY_FINAL_FLUSH_TIMEOUT`.
Move the pinned xet-core rev from 0e474005 to 388c93cc (40 commits).

- Client::upload_shard takes an optional shard upload progress callback
  and returns () (v2 shard upload API, xet-core #884). CachedXetClient
  forwards it to the inner client.
- Upload sessions now report transfer telemetry to CAS and await the
  terminal document in finalize(), up to 2 s by default (xet-core #932
  to #937). A synchronous close() would pay that on every write, so
  HF_XET_TELEMETRY_FINAL_FLUSH_TIMEOUT=0s sends it detached. The usual
  opt-out variables (HF_HUB_DISABLE_TELEMETRY, DO_NOT_TRACK,
  HF_XET_TELEMETRY_ENABLED=false) still apply.
- Download buffer defaults are now derived from usable memory (xet-core
  #943). hf-mount still sets the size and limit; only the per-file part,
  which it does not set, follows the new default.
- Also brings sha2 0.11 and the h2, rustls and der security bumps.
@XciD
XciD force-pushed the chore/bump-xet-core branch from 4a57b10 to 64be18f Compare September 30, 2026 06:50

This branch has not been deployed

No deployments
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.

1 participant