mirror of
https://github.com/qdrant/qdrant.git
synced 2026-07-23 11:11:00 -05:00
d75d805533
* Strict mode: add `max_disk_usage_percent` Mirrors `max_resident_memory_percent`: rejects disk-consuming update ops (upsert, set/overwrite payload, update vectors) when the filesystem hosting Qdrant storage is filled above the configured percentage. Delete-style ops remain allowed so callers can free disk. Disk usage is sampled via `statvfs` and TTL-cached for 5s (same cadence as the resident-memory reader) so high-RPS request paths don't hammer the syscall. Reader is keyed by path in `common::disk_usage` and returns `None` on stat failure — callers (the strict-mode check) treat `None` as "skip", matching the memory-check behaviour. Plumbing follows the existing pattern: field on `StrictModeConfig` (+ output/diff/Hash), gRPC proto field `22`, validation 1..=100, REST/proto conversions, and the hook into `check_strict_mode_toc_batch` alongside the memory check (both guarded by `any_consumes_memory`). Co-authored-by: Cursor <cursoragent@cursor.com> * Fix CI: Windows disk_usage test + e2e WAL config - `missing_path_returns_none` panicked on Windows because `GetDiskFreeSpaceEx` succeeds for non-existent paths (it resolves up to the containing drive). Relax the assertion to "must not panic; if a value is returned it must be well-formed". The contract we care about (None on failure) is platform-defined, not something we can portably force. - e2e test failed at batch 0 with "WAL buffer size exceeds available disk space": Qdrant's existing per-shard `DiskUsageWatcher` enforces `free >= 2 * wal_capacity_mb` and the default WAL didn't fit in the 50 MB tmpfs. Bump tmpfs to 200 MB and shrink `wal_capacity_mb` to 1 MB (same pattern as `test_low_disk.py`) so our strict-mode gate is the one that fires, not the WAL pre-check. Raise the gate threshold to 50% to match the larger headroom. Co-authored-by: Cursor <cursoragent@cursor.com> --------- Co-authored-by: Cursor <cursoragent@cursor.com>