168 lines
29 KiB
Markdown
168 lines
29 KiB
Markdown
- 2026-09-11: Projekt založen. Uživatel ho chce jako úložiště pro admin/root poznámky — infrastruktura, servery, provoz, podobně. Záměrně volné zaměření, strukturu a upřesnění odkládá na později. prompt.md naplněn základním homelab kontextem (Proxmox cluster, wood/pivo/nvidia/devlin.hell, Zabbix, zálohy), state.md obsahuje výchozí „kde to je / co dál".
|
||
- 2026-09-11: Presun LibreChat podman topicu z projektu ai do devops (tematicky patri sem). Artefakt librechat-podman presunut z projects/ai/artifacts/ do projects/devops/artifacts/ (README + quadlet unity). Kontext: OpenWebUI zakazano (RAM problemy), jako nahraada LibreChat; uzivatel si tema nejdřív nacte sam a rozhodne o pristupu — agent dodava info, nereshi rozhodnuti. Soucasti presunu i souhrn diskuse o podman+systemd (generate systemd deprecated od 4.4, quadlet jako hlediska, ne hotova volba).
|
||
- 2026-09-11: Doplneni motivace pro LibreChat: chci neco lite, kde snadno muzu menit LLM modely, testovat tool calling, mit preddefinovane system prompty, vyuzivat skills (LibreChat ma vlastni Skills/Agents system). OpenWebUI odstraneno kvuli RAM; LibreChat ma byt lehci alternativa s temito vlastnostmi.
|
||
- 2026-09-13: Research sandbox kontejnerů pro AI harness (LibreChat Code Interpreter). Vybrané řešení: LibreCodeInterpreter (https://github.com/GlydePath/librecodeinterpreter) — komunitní nsjail reimplementace LibreChat Code Interpreter API, Apache 2.0, GHCR image `ghcr.io/usnavy13/librecodeinterpreter` (amd64+arm64, pinovat tag, ne main). Stack: 1 API kontejner + Redis + Garage (S3). 13 jazyků (Python, JS, TS, Go, Java, C, C++, PHP, Rust, R, Fortran, D, Bash), Python REPL pool ~20-40ms exec, ostatní jazyky one-shot. Sandbox default bez sítě; ENABLE_SANDBOX_NETWORK=true zapne inline allowlist HTTPS proxy (pip/npm/cargo instally, cache ve skill-deps volume). Autentizace: x-api-key header nebo URL credentials (LibreChat LIBRECHAT_CODE_BASEURL=https://<key>@host/v1 → Basic auth).
|
||
|
||
Speciální práva kontejneru (klíčové zjištění z researchu):
|
||
|
||
- `cap_add: SYS_ADMIN` — nsjail potřebuje clone namespaces, mount, cgroups. NEVYJEDNATELNÉ, bez toho nsjail nefunguje. SYS_ADMIN je nejsilnější kontejnerová capa — kontejner s ní je de facto root co umí mountovat.
|
||
- `cap_add: NET_ADMIN` — pouze pro ENABLE_SANDBOX_NETWORK=true (iptables egress allowlist v sandbox netns). Při offline sandboxech lze vynechat.
|
||
- `security_opt: apparmor:unconfined` — nutné na hostech s AppArmor (Ubuntu/Debian), jinak mount() v nsjailu padá na EPERM. Na distrubu bez AppArmor (Alpine) no-op.
|
||
- `init: true` (tini) — reapuje zombie nsjail/python child procesy.
|
||
|
||
Význam pro nasazení: API kontejner běží jako near-host privilegia (root + SYS_ADMIN + unconfined) na sdíleném kernelu. Nejedná se o „kontejner izoluje nevěřený kód", ale „API proces musí být skoro-host, aby mohl sám izolovat kód pomocí nsjailu". Skutečná sandbox hranice pro LLM kód je nsjail (PID/mount/net namespaces, seccomp, cgroups, rlimits, non-root UID 1001) — sdílený kernel. Únik z nsjailu = kernel hostu = všechno co na něm běží.
|
||
|
||
Závěry nasazení:
|
||
- Proxmox VM > LXC pro tento use case (nevěřený LLM kód + near-host capy kontejneru). V LXC by únik z nsjailu dosáhl PVE host kernelu; VM dává druhou hranici + možnost nested virt pro microsandbox později.
|
||
- Alternativa: běží-li Docker VM jako čistý AI stack (LibreChat + interpreter, žádná produkční data), je jeden host logický celek. Na obecném provozním Docker hostu raději dedikovaná malá VM (1.5-2 GB RAM).
|
||
- Rootless podman nefunkční out-of-the-box (user namespace v user namespace, cgroup delegace) — projekt to netestuje; rootful podman/quadlet OK.
|
||
- Kompromis vs oficiální codeapi: ta řeší stejný problém microVM režimem (libkrun), ale stojí 5 komponent + Redis + MinIO.
|
||
- 2026-09-14: Záznam reportu od Claude Code (uživatel ho přinesl 2026-09-13): „Negativní zjištění — nvidia.hell / ollama" — co selhalo a co je slepá ulička z incidentů 12.–13. 9. 2026. Plný report uložen verbatim jako artifact: `projects/devops/artifacts/2026-09-13_ollama-nvidia-negative-findings.md` (report odkazuje na history.md a knowledge.md na stroji, ty v workspace nejsou — jen v artifactu).
|
||
|
||
Shrnutí obsahu:
|
||
|
||
**Pojistky, které selhaly:** earlyoom zavržen a odinstalován — killuje llama-server uprostřed CUDA initu, čímž nvidia driver natrvalo ztratí napinovanou host paměť (po ~15 killech −9,27 GiB, kladná zpětná vazba: méně RAM → dřívější killy). Výchozí earlyoom konfigurace by nezasáhla nikdy (obě podmínky mem+swap musí platit současně); SIGKILL práh je polovina zadané hodnoty, musí se psát `-s 100,100`. MemoryHigh mezi spotřebou a MemoryMax = past (gemma4 host buffer 5901 MiB padl doprostřed → 84k reclaimů, load visel 600 s bez chyby) — při „rychlém selhání" se MemoryHigh nesmí nastavit. systemd-oomd nepoužit (PSI varianta earlyoomu, čekali by týž leak).
|
||
|
||
**Slepé uličky v konfiguraci ollamy:** žádný admission control v 0.33.2 (přeteče do CPU vždycky); `OLLAMA_NO_MMAP` neexistuje (issue #4895, PR #6854 nesloučen); navýšení RAM neřeší nic — podmínka mmap disable je `FreeMemory < modelSize + max(8GB, Total/10)`, headroom konstanta 7,5 GiB, potvrzeno 3 loady při různé volné paměti (uživatel RAM naopak ubral z 11,4 na 9,5 GiB); limitování počtu modelů vyhozeno (stroj shodila host RAM, ne VRAM, a MAX_QUEUE nesahá na sekvenci loadů); upgrade na 0.34.0 nic řeší; `OLLAMA_KV_CACHE_TYPE=q4_0` globálně rozbíjí modely s `n_embd_head_k=80` (granite-code padl 6×, stále nastaveno, neopraveno); gemma4 se na stroj nevejde nikdy (Per-Layer Embeddings drží embeddingy na CPU záměrně, host drží 5901 MiB i při 16 GB volné VRAM; kontraintuitivně: čím prázdnější karta, tím spíš se mmap vypne).
|
||
|
||
**Chyby v systemd konfiguraci:** StartLimit* patří do `[Unit]` (v `[Service]` se tiše ignorují); `systemctl show` property je `RestartUSec`; MemoryMax nelimituje swap → s 32 GB swapu thrashing místo OOM killu, tvrdý strop až MemorySwapMax; instalátor ollamy bezpodmínečně přepisuje unit soubor (vlastní nastavení do drop-inu, ne kopírování unitu); limity z 12. 9. z override.conf nevysvětleně zmizely (21:10 zapsány, 21:44 pryč) — příčina nezjištěna, proto záloha override.conf.bak-20260913; v drop-inu překlep `LLAMA_MAX_LOADED_MODELS` (má být OLLAMA_).
|
||
|
||
**Co nástroje neukážou:** napinovanou paměť nevidí ps/nvidia-smi/systemd-cgtop/proc-meminfo (AnonPages 135 MiB, ale anon sum 9,4 GiB) — jediný indikátor je `nr_foll_pin_acquired − nr_foll_pin_released` v /proc/vmstat (skript ~/bin/nvidia-reload na nvidia.hell); sar dopad „unaccounted" paměti z 13:40 vysvětlen jako týž leak; restart ollamy leak neuvolní — paměť uteče z cgroup do system.slice, uvolní jen driver teardown/reboot; Proxmox ballooning nevhodný pro LLM stroje (počítá cíl z volné paměti hostitele, ~10 MB/s navýšení vs 17 s load modelu).
|
||
|
||
**Opravené chybné závěry:** spouštěčem nebyl LibreChat (jen zesilovač — retry po timeoutu), ale samotný model; embedding drží nanobot.hell (192.168.4.64), ne LibreChat — nanobot je zdroj dávek desítek requestů přes ~10 modelů; regrese 0.32.10 není jen Vulkan na iGPU (my CUDA + diskrétní karta, jiný spouštěč, stejný `--load-mode none`, potvrzuje #18373); leak vzniká i při zrušení loadu vlastním schedulerem po odpadnutí klienta (5,19 GiB) — nezáleží na tom, kdo llama-server ukončí, ale že to bylo uprostřed loadu.
|
||
|
||
**Upstream (otevřené/neopravené):** #18373 load regrese (2m34s vs 28s), #10104 zavřen bez řešení, #10341 gemma RAM na RTX 4060 Ti 16 GB (stejná karta, duplikát #10040), #8654 memory check vs mmap, #4895+PR#6854 mmap řízení. Problém široce hlášený, upstream neřeší.
|
||
|
||
**Drobnosti k opravě (otevřené):** zabbix-agent má defaultní `Hostname=Zabbix server` (má být nvidia); llama-server `--log-verbosity 4` (journald žral 1,9 % CPU, zaplevelený journal); LibreChat titleConvo posílá druhý souběžný požadavek na týž model; earlyoom ve stavu `rc` — zbývá `apt purge` (na disku /etc/default/earlyoom a .bak).
|
||
|
||
Koresponduje s dřívějším zjištěním z projektu ai (2026-09-13): Ollama na nvidia.hell v praxi nepoužitelná, memory watchdog zabíjí llama-server. Tenhle report dodává root cause: kill uprostřed CUDA loadu → leak napinované paměti, kterou neukáží standardní nástroje.
|
||
- 2026-09-14: Záznam druhého reportu od Claude Code: „Ollama na nvidia.hell — ucelený report" (stav k 2026-09-13 21:30). Uložen verbatim jako artifact: `projects/devops/artifacts/2026-09-13_ollama-nvidia-full-report.md`. Je to nadstavba předchozího „Negativní zjištění" reportu (uložený den předtím) — obsahuje kauzální řetěz, ověřená fakta, aktuální stav a todo list.
|
||
|
||
**Kauzální řetěz (5 kroků):** (1) ollama rozhoduje „fits alongside existing models" podle VRAM, ne volné RAM → pustí model i při system_free 115 MiB; (2) týž dechem vypne mmap (podmínka na 9,5 GiB stroji nesplnitelná nikdy) → model jde do anonymní paměti místo page cache; (3) gemma4 PLE drží 5,9 GiB host bufferu navíc; (4) RAM dojde → swap thrashing (pswpin 4512/s, %system 90 %, load 81, SSH nedostupné 45 min); (5) přerušený load → leak napinované paměti. Body [1] a [2] si odporují v téže vteřině.
|
||
|
||
**Nová fakta oproti předchozímu reportu:**
|
||
- **correction: rmmod nvidia driveru leak NEUVOLNÍ** — ověřeno 20:20, proběhl čistě, foll_pin delta bit za bit stejná (2 307 318 stránek). Moje předchozí shrnutí říkalo „uvolní ho jen driver teardown nebo reboot" — platí **jen reboot** (ověřeno 20:26: MemAvailable 89 MB → 7,6 GiB). Skript `~/bin/nvidia-reload` na stroji je tedy bezcenný.
|
||
- **Cgroup pojistka funguje a je ověřená**: `MemoryMax=6G`, `MemorySwapMax=0` (klíčový řádek — nedostupnost dělal swap thrash, ne OOM; MemoryMax sám swap nelimituje), `CPUQuota=200%`, `CPUWeight=20`, MemoryHigh záměrně vynechán. Plus SSH ochrana (`OOMScoreAdjust=-900`, `MemoryMin=32M` v ssh.service.d/10-oom-protect.conf). Zátěžový test 16:55–17:05 (gemma4 load, SSH heartbeat à 2 s): 240/240 úderů, 0 výpadků, load max 3,41 (vs 81 při incidentu), MemAvailable min 3204 MiB.
|
||
- **Diagnostika OOM**: `dmesg` rozlišuje `constraint=CONSTRAINT_MEMCG` (pojistka zafungovala) vs `CONSTRAINT_NONE/global_oom` (stroj sežraný leakem, pojistka se ke slovu nedostala). `failed (Result: oom-kill)` tedy neznamená automaticky zafungovaný strop.
|
||
- **První výskyt `disabling mmap` v journalu je 2026-06-05** — předtím 13 měsíců čisto. Jde o regresi, ne stávající vlastnost.
|
||
- **`sar` chybějící vzorek = sám o sobě důkaz** (stroj nestíhal ani cron à 10 min) — datování začátku incidentu.
|
||
- **Zavržené nově:** zvedání `OLLAMA_LOAD_TIMEOUT` („turns a hard failure into a slow success" — jen by prodloužilo thrashing); Proxmox ballooning → řešení `balloon: 0` + pevná paměť (pvestatd počítá cíl z volné paměti hostitele, ~10 MB/s vs 17 s load modelu).
|
||
- **Capability `tools` ≠ model nástroje použije**: mistral:latest dostal stejných 5 nástrojů jako glm-5.3, nezavolal ani jeden; flag říká jen, že šablona podporuje tools. Seznam modelů bez `tools` capability (nikdy nebudou fungovat): llama3, llama2-uncensored, tinyllama, aya, phi4, phi3.5, codellama, exaone-deep, deepseek-coder-v2, granite-code:8b.
|
||
- **Prostředí:** VM pod pve.hell (192.168.4.47), RAM snížena 11,4 → 9,5 GiB, swap 32 GB swappiness=60, 4 jádra, RTX 4060 Ti 16 GB, ollama 0.33.2 nativně. Skutečný zdroj zátěže = nanobot.hell (192.168.4.64), LibreChat jen zesilovač.
|
||
- **Kuchařka pro triáž** (awk foll_pin delta, kontrola cgroup limitů — už jednou zmizely, constraint grep, journalctl IP grep, sar postmortem) + **zálohy a rollback** (override.conf.bak-20260913, ~/backup/ollama-20260912-2108/, upgrade skripty).
|
||
|
||
**Otevřené body (prioritně, z §11):** (1) zastavit dávky z nanobot.hell — bez toho leak zpátky během minut; (2) retest cgroup pojistky bez MemoryHigh (odblokováno rebootem, kritéria: heartbeat bez výpadku, MemAvailable > 2 GiB, constraint=MEMCG); (3) doladit MemoryMax podle memory.peak z retestu; (4) rozhodnout osud gemma4 (PLE ~5,9 GiB host bufferu, na 9,5 GiB stroji nikdy); (5) OLLAMA_KV_CACHE_TYPE=q4_0 zrušit nebo nepoužívat granite-code; (6) drobnosti: apt purge earlyoom, log-verbosity 4, zabbix Hostname, LibreChat titleConvo, otázka monitoringu (hlídač co killuje = zavržená cesta).
|
||
|
||
**Stav po rebootu 20:26:** stroj zdravý (MemAvailable 7,6 GiB, 0 OOM killů), pojistka aktivní ve správné podobě.
|
||
- 2026-09-14: correction: K bodu „Zastavit dávky z nanobot.hell (192.168.4.64)" z reportu i mého shrnutí z 2026-09-14 — nanobot.hell **není trvalý zdroj zátěže**. Dávky chat requestů přes ~10 modelů byly **testovací tool-calling requesty** (testy schopností lokálních modelů, viz projekt ai, memory 2026-09-12/13 — skript `projects/ai/artifacts/ollama-toolcall-test.py`). Jednorázová testovací zátěž, ne provoz.
|
||
|
||
Běžný provoz nanobota na lokální ollamu **nesahá**: používá ji jen na (a) embeddingy (`qwen3-embedding:0.6b` pro wiki skill, periodicita z wiki syncu) a (b) cloud modely (`:cloud` presety, `glm`/`kimi` — ty neběží lokálně, jen se proxy přes ollama endpoint). Chat na lokálních modelech není součást provozu.
|
||
|
||
Důsledek pro open body: bod 1 reportu („zastavit dávky z nanobotu — bez toho leak zpátky během minut") **neplatí jako provozní riziko**, jen jako poučení pro případné budoucí testovací dávky. Zbylé open body (retest pojistky, MemoryMax, gemma4, KV_CACHE_TYPE, drobnosti) zůstávají. Trvalé součásti povrchu nanobot→ollama zůstávají embeddingy — izolace embeddingů na samostatný statický server (llama.cpp/vLLM) tím dává ještě větší smysl: po ní lokalně nezůstane téměř žádný nanobot provoz, který by ollamu mohl shodit.
|
||
- 2026-09-14: Závěr embed-parity snažení (qwen3-embedding:0.6b, ollama vs llama.cpp server na :8081, `--pooling last`): parita **neexistuje** — stejné vstupy dávají fundamentálně odlišné vektory (i jednotokenový vstup `cat` → cosine 0,36; delší vstupy 0,87–0,93), reuse ollama blobu v llama.cpp paritu nezajistí, pooling ani input wrapping (speciální tokeny, chat template) rozdíl nevysvětlují (vše systematicky vyzkoušeno a vyloučeno). Uživatelovo závěrečné rozhodnutí: **při přechodu na čistý llama.cpp se reindexuje celá wiki báze** — žádná snaha o bezreindex migraci; přepnout endpoint v wiki/config.yaml na nvidia.hell:8081 + full reindex jedním krokem.
|
||
- 2026-09-14: Z článku "10 Linux Tools" potvrzený stávající tooling: uživatel používá tmux, lazydocker, bat, mosh. Z výčtu nevyužité kandidáti: fzf, zoxide, ripgrep, fd, delta, btop.
|
||
- 2026-09-14: Druhý článek ("10 CLI Tools That 10x Backend Productivity") — potvrzeno: just už zkoušel a líbí se mu hodně (jedina výtka: málo rozšířený), jq používá, zůstává u curl (httpie viděl, ale nepřepnul). Další kandidáti z článku k nezavedení: watchexec/entr, xh, eza, mise, pgcli, gh.
|
||
- 2026-09-14: Z článku (Medium, DataExpert, 2026-09-03) a online verifikace — poznámka ke stacku DuckDB + Apache Iceberg + dbt:
|
||
|
||
Use case: celý enterprise lakehouse workflow (incremental loading, SCD Type 2, partition pruning, schema evolution, data quality testy, compaction) lze prototypovat a učit na laptopu za $0, místo placeného Snowflake/Databricks compute. dbt-duckdb adapter = stejné SQL/modely lokálně i na produkci (Snowflake/BigQuery), mění se jen dbt target. Relevance pro homelab: levná varianta pro vlastní analytické pipeline na malých/ Středních datech (10–100 GB), kde by jinak byl nutný Spark cluster.
|
||
|
||
Ověřené fakta (primární zdroje):
|
||
- DuckDB v1.5.3 (2026-05-29): plná podpora zápisu do Iceberg tabulek — MERGE INTO (merge-on-read, positional deletes), ALTER TABLE (schema evolution, metadata-only), partition transforms bucket/truncate, Iceberg V3 (deletion vectors jako Puffin, VARIANT, TIMESTAMP_NS). Dřív jen čtení; zápis vyžadoval Spark. Zdroj: https://duckdb.org/2026/05/29/new-iceberg-features a https://duckdb.org/2025/11/28/iceberg-writes-in-duckdb
|
||
- DuckLake v1.0 (2026-04-13): lakehouse formát, metadata v SQL databázi (catalog SQLite/Postgres/DuckDB) místo metadata souborů v object storage; data inlining (default threshold 10 řádků) řeší small-file problem; volitelná Iceberg kompatibilita. Zdroj: https://ducklake.select/2026/04/13/ducklake-10/
|
||
- Apache Polaris: free self-hostable Iceberg REST catalog, top-level Apache projekt (únor 2026) — náhrada Hive Metastore/Glue pro lokální setup.
|
||
- AWS acquirenul DuckLabs (tým za DuckDB, srpen 2026); projekt zůstává MIT pod nezávislou DuckDB Foundation.
|
||
|
||
Benchmarky jen z Medium článku, neověřitelné, brát s rezervou: FinQore pipeline 8 h → 8 min (60×, migrace z Postgres); dashboard dotazy 200–400 ms vs 2–5 s Snowflake X-Small; MotherDuck 6–7× rychlejší než ekvivalentně ceněné Snowflake/Redshift na 10–100 GB.
|
||
|
||
Limity stacku: DuckDB 1 writer (multi-process writes selhávají), Iceberg+Parquet 2–3× pomalejší než nativní DuckDB formát, small-file/manifest explosion se na laptopových datech neprojeví — produkční operační zkušenost se musí nabýt na produkci.
|
||
- 2026-09-14: Poznámka z článku (Medium, Jesse L, ~2026-11): **Posting** — TUI HTTP klient jako alternativa k Postman/Insomnia. Relevance pro homelab: běží v terminálu přes SSH, takže se dá testovat API přímo ze stroje, který na něj dosáhne (uvnitř VPC, za bastionem, interní služby v Proxmox/LXC) — žádný port forwarding ani tunel GUI klientu.
|
||
|
||
Klíčové fakta:
|
||
- Python + Textual framework; zdroj https://github.com/darrenburns/posting, dokumentace https://posting.sh; verze k psaní článku v2.10.0
|
||
- Instalace: `uv tool install --python 3.13 posting` (izolovaný Python, nesahá na systémovou verzi); Homebrew/NixOS oficiálně nepodporované
|
||
- Requesty jsou čitelné **YAML soubory** (`.posting.yaml`), kolekce = adresář — commitovatelné vedle kódu, čitelné diffy v PR, žádný export/import JSON s generovanými ID
|
||
- Prostředí přes `.env` soubory: `posting --env dev.env` / `posting --env staging.env` — stejné env soubory jako zbytek projektu, tajemství se necommitují
|
||
- Import z Postman/OpenAPI: `posting import -t postman collection.json` / `-t openapi openapi.yaml` — z OpenAPI specu lze vygenerovat sadu requestů bez ruční práce
|
||
- Klávesy: `Ctrl+P` command palette (jako VS Code), `Ctrl+J` odeslat, Tab/j/k navigace, jump mode s písmeny na widgetech
|
||
- Konfig: `~/.config/posting/config.yaml` (témata, keybindings, default headers) → vhodné do dotfiles repa; default kolekce `~/.local/share/posting/default`
|
||
- `posting locate config` / `posting locate collection` vypíše cesty
|
||
|
||
Kdy se nehodí: automatizované testy/CI (na to pytest+httpx nebo newman), sdílené workspaces/mock servery (komerční klienty), API design/dokumentace.
|
||
|
||
Alternativy: **atac** (Rust TUI, podobný cíl), **httpie**/**curlie** (CLI, rychlejší na jednorázovky), **Bruno** (GUI, ale stejná file-based Git-friendly filozofie).
|
||
|
||
Vzetá idea i bez instalace: API requesty patří do repa jako soubory vedle kódu, který testují — ne do proprietárního formátu v cizím cloudu.
|
||
- 2026-09-14: Poznámka z článku (Medium, Jesse L) + dohledané info z primárních zdrojů: **below** — "time traveling resource monitor" od Meta (facebookincubator), Rust TUI. Neustále nahrává detailní stav systému (per-process, per-cgroup, PSI) na lokální disk a umožňuje replay jakéhokoli okamžiku minulosti: `below replay -t "3m ago"`. Zaplněná díra: live monitory mají detail bez paměti, metriky (Prometheus/Zabbix) paměť bez detailu — "který proces to způsobil v 3:07" neodpoví ani jeden.
|
||
|
||
Relevance pro homelab (nvidia.hell incident 12.–13. 9.): přesně tenhle use case — swap thrash, SSH nedostupné 45 min, po návratu žádné per-process data. below s cgroup pohledem + PSI by ukázal kauzální řetěz zpětně. PSI (Pressure Stall Information) je relevantní i jako koncept: "disk je busy" vs "procesy čekají na disk" — tlak, ne vytížení, ukazuje bottleneck.
|
||
|
||
Ověřená fakta (primární zdroje):
|
||
- Repo: https://github.com/facebookincubator/below, Apache 2.0, ~2,5k stars. Poslední release **v0.11.0 (24. 9. 2025)** — article verze potvrzena. Vývoj: Meta resource control team (kernel/container/hardware lidi) s inputem atop power userů.
|
||
- Balíčky: **Fedora 34+, Alpine 3.17+, Gentoo (sys-process/below), Amazon Linux 2023.9**. **Debian/Ubuntu apt balíček NENÍ** — na Debian strojích (celý Proxmox cluster, LXC) nutné `cargo install below` z source (build deps v docs/building.md: clang, libelf-dev, libssl-dev, zlib1g-dev…).
|
||
- Dlouholeté defekty atopu, proti kterým below stavěli (Fedora Magazine): žádná cgroup podpora; custom delta compression ztrácí data zrovna pod resource pressure; strná learning curve.
|
||
- Comparison doc (oficiální): below "goes to great lengths to avoid priority inversions during host resource contention"; **žádná vestavěná komprese dat — doporučují btrfs transparent compression**. Zbylé alternativy: htop (žádná historie), sysstat/sar (binárka, žádný interaktivní interface, žádné cgroups), cAdvisor (cgroup1 only, vyžaduje externí storage), collectd (žádné UI).
|
||
- Subcommandy: `below live` / `below replay -t "5m ago"` / `below dump` (JSON/CSV/OpenMetrics → Prometheus/Grafana, contrib/grafana) / `below snapshot` (replayovatelný soubor time range → přiložit k incident ticketu). Klíče TUI: **t/T** vpřed/vzad, **p** process view, **s** system view, **z** zoom do cgroup, **?** help.
|
||
- Data ukládá do **/var/log/below/store** — nutné ohlídat místo na disku (nahrávání běží continuous, retention konfigurovatelné).
|
||
|
||
Bezpečnost (důležité při instalaci):
|
||
- **CVE-2025-27591 / RUSTSEC-2025-0149** (CVSS 7.3): do v0.8.1 below vytvářel world-writable `/var/log/below` (mode 0777) → symlink attack = lokální privilege escalation. **Opraveno od v0.9.0** — instalovat jen >=0.9.0, současný v0.11.0 čistý.
|
||
- Dále v0.8.1 i po opravě: vnitřní data ve `/var/log/below/store` world-readable — info leak pro neprivilegované lokální uživatele.
|
||
|
||
Limity: Linux only, **cgroup v2 only** (Proxmox/Debian moderní = OK), root pro plnou viditelnost, per-host (žádný fleet view), musí běžet dopředu ("kouřový detektor" — po incidentu instalovaný below nic neříká).
|
||
|
||
Neověřitelné/nezjištěné: přesná spotřeba místa na disk per den a reálný CPU overhead daemonu — v dokumentaci čísla nejsá,Community údaje chybí; před nasazením na stroj s malým rootem změřit vlastní.
|
||
- 2026-09-14: Z článku o ncdu (Medium, Jesse L, ncdu 1.19): uživatel ncdu aktivně používá a je spokojený. Vyhodnocení tipů z článku:
|
||
|
||
Pro uživatele potenciálně nové/užitečné:
|
||
- **Export/import scanu**: `ncdu -0 -o scan.json <dir>` (scan do JSON bez UI) + `ncdu -f scan.json` (prohlížení kdekoli) — offline analýza, scan pod rootem → prohlížení pod běžným uživatelem, scp JSON na jiný stroj, týdenní scany z cronu → diff růstu adresářů („roste 3 GB/týden od března").
|
||
- **`-r` read-only** — na produkci zakáže delete klávesu `d`; doporučenej habit `ncdu -rx -o /tmp/scan.json /`.
|
||
- **`C` sort podle počtu položek** — najde adresáře s miliony malých souborů (nevyniknou podle velikosti, ale jsou pomalé na zálohu/smazání).
|
||
- **`-e` extended info** — mtime v detailech (`i`), rozlišení starého bordelu vs čerstvého nárůstu.
|
||
- **`b`** — otevře shell v prohlíženém adresáři.
|
||
- **`--exclude-caches`** (CACHEDIR.TAG), **`--exclude-kernfs`** (procfs/sysfs), **`-q`** quiet mode pro pomalé SSH.
|
||
- **ncdu 2.x** — rewrite v Zigu, rychlejší na obřích stromech (miliony souborů), lepší hardlink handling; distribuce většinou shippují 1.x, interface téměř identický.
|
||
|
||
Zbytek článku (základní navigace, instalace, `-x`, alternativy gdu/dust/duf/baobab) známý/irrelevantní.
|
||
- 2026-09-14: Potvrzený top tip z ncdu článku: kombinace `ncdu -0 -o scan.json /var` → `ncdu -f scan.json` — uživatel ji hodnotí jako největší přínos (mega hodí se) — přenos výsledků na jiný stroj, pozdější zkoumání bez rescenu, zvlášť u velkých stromů s mnoha soubory.
|
||
- 2026-09-14: Uživatel preferuje rsync místo scp pro přenos souborů (např. ncdu scan JSONů mezi stroji). V budoucích doporučeních a skriptech používat rsync, ne scp.
|
||
- 2026-09-14: Doplněná čísla ke studii HDD spolehlivosti (Siemroth & Park, "Are There Manufacturer Differences in Hard-Drive Reliability?", IEEE Transactions on Cloud Computing 14(2), pp. 1015–1024, DOI 10.1109/TCC.2026.3679404; data Backblaze 2013–Q2/2025) — k výchozímu článku z VTM.cz přidáno.
|
||
|
||
Primární zdroje:
|
||
- https://arxiv.org/abs/2606.29078 (arXiv, plný text: https://arxiv.org/html/2606.29078)
|
||
- https://doi.org/10.1109/TCC.2026.3679404 (IEEE Xplore)
|
||
- https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (Drive Stats dataset, CSV + Iceberg)
|
||
- Sekundárně: https://www.tomshardware.com/pc-components/hdds/peer-reviewed-study-of-443000-backblaze-drivers-ranks-hgst-most-reliable-and-toshiba-least
|
||
|
||
**Hazard ratios vůči Seagate (Table I, robustní SE, p<.001 pokud není uvedeno jinak):**
|
||
- Cox: HGST 0,395 (SE 0,009), Toshiba 1,070 (SE 0,033, signifikantní jen na 5 % — nejnástojnější rozdíl dvojice), WD 0,514 (SE 0,021), teplota 1,021/°C
|
||
- Weibull: HGST 0,411, Toshiba 1,073, WD 0,520 — oba modely do 2 p.b. od sebe, výsledky robustní
|
||
- Test HGST = WD: p = 0,000 — HGST signifikantně lepší než WD i po akvizici (možný shared technology/procedures od 2012)
|
||
|
||
**Vzorek (detaily přípravy dat):**
|
||
- 443 156 HDD; 442 998 s kladnou durací; v regresích 442 992 (6 bez teplot); 21 195 s neznámým datem instalace vyloučeno (<5 %); 4 Samsung HDD a SSD vyloučeny
|
||
- 146 943 disků (~31 %) vyřazeno bez poruchy (Backblaze personal communication: upgrade na větší kapacity, úspora proudu) — right-censored, v modelech ponechány
|
||
- Jen 0,52 % disků má duraci > 10 let → výsledky jen krátkodobá/střednědobá spolehlivost
|
||
|
||
**Teplota (Table I):** HR 1,021 na 1 °C; 10 °C → 1,021^10 = 1,231 ≈ +23,1 %. Vnitřních 90 % průměrných teplot v datech: 22,5–40 °C. Příklad z paperu: disk na 40 °C s AFR 2 % → snížení o 10 °C dá ~1,625 %.
|
||
|
||
**Kapacita (Table III, lineární člen místo dummies):** HR 0,966 na 1 TB (−3,4 %, p<.001; Weibull 0,961). Footnote: 1TB disk s AFR 2 % → 2TB disk ~1,93 %. Vysvětlení: novější výrobní procesy (Damascene head fab u WD), heliová náplň (nižší aerodynamický odpor, méně tepla, méně opotřebení ložisek), posun poptávky k enterprise; SMR výjimka (zvyšuje komplexitu, spíš nepřispívá). Form factor 2,5" neověřitelný — jen ~0,6 % vzorku.
|
||
|
||
**Pozice v datacentru (Table II, cluster controls, podvzorek 355 429 disků — ztráta ~90 000, cluster proměnná až od Q2/3 2023):**
|
||
- 7 clusterů, HR: cluster 20 = 1,287 (nejhorší), 31 = 1,229, 50 = 1,154, 40 = 0,736, 52 = 0,511, 60 = 0,489 (nejlepší) → worst/best ≈ 2,63× i po konrolách (výš bez kontroly teploty)
|
||
- S cluster controls: HGST 0,833, Toshiba 1,029, WD 0,471 — pořadí a poměry značek prakticky nezměněné; autoři ale preferují Table I (větší vzorek)
|
||
|
||
**Věk disků (Figure 2, non-parametrický odhad, Epanechnikov kernel bw 5 měsíců):**
|
||
- Do 50 měsíců žádná značka > 2 poruchy/1000 disků/měsíc (~2,4 % anualizovaně)
|
||
- 50–100 měsíců: Toshiba 5–6/1000/měsíc, ostatní ≤ 2,5/1000/měsíc
|
||
- Toshiba po 60 měsících: >4× nárůst měsíční poruchovosti vs mladý věk — spike, který žádná jiná značka nemá
|
||
- Seagate stabilní, HGST mírně volatilní ale nejnižší; WD lepší než HGST po ~40 měsících (ale malý vzorek — WD ve velkém až od ~2024, <1000 disků at risk v 60. měsíci; HGST <1000 až ~115. měsíc)
|
||
- Věk není lineární ani monotónní efekt; Toshiba se v průběhu života mění až 5×
|
||
|
||
**Ekonomika (rovnice P_premium ≤ Δ×C×L):**
|
||
- Příklad: L=10 let, C=$100 (náhrada), Δ Seagate→HGST = 0,02×0,59 = 0,0118 → max přirážka za HGST $11,8
|
||
- Backblaze (~300k aktivních disků): zdvojnásobení AFR 1 % (Toshiba)→2 % (Seagate) = +3000 výměn/rok; při stejné ceně disků flota Seagate stojí >$3m navíc
|
||
|
||
**Srovnávací kontext Backblaze Drive Stats (Q1 2026 snapshot, primární zdroj backblaze.com):** 341 263 disků, 1 030 poruch, AFR Q1/2026 = 1,24 %; rok 2025 AFR = 1,36 % (115,6M drive-days, 4 317 poruch); lifetime AFR = 1,39 % (529,9M drive-days, 20 212 poruch). Podíl značek: Toshiba 33,93 %, Seagate 33,02 %, WDC 25,30 %, HGST 7,75 %. Dataset open-source, CSV i Apache Iceberg formát (query přes DuckDB/Trino/Snowflake).
|
||
|
||
Praktický takeaway pro nákup disků do homelabu: HGST už nejde koupit nové (WD brand zrušen), takže reálné pořadí dnešních značek: WD > Seagate ≈ Toshiba, ale Seagate/Toshiba ~2× vyšší poruchovost; nižší teplota a vyšší kapacita pomáhají. Závěry platí pro enterprise disky v datacentru — na konzumerní disky nejsou nutně přenositelné, workload data nejsou k dispozici.
|