mirror of
https://github.com/qdrant/qdrant.git
synced 2026-08-03 08:30:55 -05:00
c150bd5caa
* 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>
TLS test
Regenerate certificates
- run
PROJECT_ROOT/tests/e2e_tests/test_data/gen.sh - replace old certificates in
PROJECT_ROOT/tests/e2e_tests/test_data/certwith the newly generated ones
Data compatibility test
In order to detect quickly breakage of storage compatibility, we check that the current code understands the storage format from the latest stable release.
To not burden the git repository with tracking the large binary files, we are pushing storage archives to our GCP bucket.
As features are added, the storage format may change. This means updating the reference storage data and snapshot. This is done by running the gen_storage_compat_data.sh script.
Regenerate storage data
Follow those steps to recreate the reference storage data and snapshot.
- run
PROJECT_ROOT/tests/e2e_tests/test_data/compatibility/gen_storage_compat_data.sh - make sure to pick the right version when asked for which system generated the files
- push the new archives to the GCP bucket (ask for the credentials if you don't have them)