Files
libfreemkv/docs/file-sector-source-macos.md
T
Matthew Jackson 6e14fc0c0c libfreemkv: 1.7.0 groundwork — sector-recycle soundness + CI hardening
Security
- Remove the unsafe Vec::set_len over recycled sector buffers — UB reachable
  from safe code (GHSA-j8ww-f5fg-9pmh, low). Uses Vec::resize; pooling unchanged.

CI / tooling
- clippy on stable with the MSRV single-sourced from Cargo.toml; cargo-deny
  dependency-audit gate with first-party git sources allowed (#15); audience-based
  comment-guard (#17).

Docs
- README (keydb ownership, BD-J parser count), drive-access transport/reset
  notes, mux timeline module-doc links.
2026-09-02 12:40:55 -07:00

1.3 KiB

file_sector_source::macos

macOS has no direct POSIX_FADV_SEQUENTIAL equivalent; the idiomatic hint is fcntl(F_RDADVISE, &radvisory) describing the byte range you intend to read soon. The open-time sequential hint points it at the whole file (clamped to RDADVISE_MAX_BYTES so a multi-TB ISO doesn't ask the kernel to prefetch everything at once).

RDADVISE_MAX_BYTES

Cap on the byte length passed to F_RDADVISE. Asking for a multi-GB readahead window is counterproductive — the OS doesn't have that much cache to throw at one fd. 64 MiB is generous for our use case (sweep, mux) so the kernel's prefetch keeps pace with our app-level pipeline depth.

drop_window

macOS has no direct POSIX_FADV_DONTNEED equivalent for a byte range. fcntl(F_NOCACHE) would disable caching globally on the fd (too coarse — we want the unread region to still benefit). Best approximation: no-op. macOS's unified buffer cache is generally less prone to the pin-everything pathology that triggers the regression on Linux NFS clients.

prefetch

Async-prefetch the byte range [offset, offset+len). macOS uses the same fcntl(F_RDADVISE, &radvisory) primitive as the open-time sequential hint, just targeted at a moving window instead of the whole file. The kernel queues I/O for the requested range and returns immediately.