---
name: project-seaweedfs
description: "SeaweedFS na Tower1 (192.168.1.50) — kontejner, rozdělení dat, noční backup filer metadat na tower .76"
metadata: 
  node_type: memory
  type: project
  originSessionId: 958cbde4-e6aa-463e-8d0e-cd7c3f7bf9ec
---

SeaweedFS „na hraní" na Tower1 Unraid (192.168.1.50, root, heslo Vlado7309208104++; SSH jen heslem, klíč nejde). Postaveno 2026-06-12.

- Kontejner `seaweedfs` (chrislusf/seaweedfs, host network), `weed server -filer -s3`: master :9333, volume :8080, filer :8888, S3 :8333 (anonymní). **Limit volume = 30 GB** (ne 1 GB — dřívější údaj v Triliu byl chybný; ověřeno z `/dir/status` pole Version="30GB"), max 50 slotů → efektivní strop ~1,5 TB, pod tím array ~11,5 TB volných. Kapacita není omezení.
- **Upload do Fileru: `PUT` raw tělo** (POST multipart na první zápis timeoutuje!). `requests` i v python-runner kontejneru. Dedup podle SHA-256 obsahu. Cesta `/mail-attachments/ab/cd/<hash>` (content-addressed, ab=hash[:2], cd=hash[2:4]).
- **Sdílený modul `seaweed_store.py`** (`/scripts/seaweed_store.py` na Unraidu .76) — jednotné schéma cesty/URL/PUT pro obě větve příloh, takže identický obsah z Graphu i mailstore skončí na téže cestě a globálně se dedupuje. Funkce `store(sha256, data, mime) -> (path, url, uploaded)`.
- **Tři větve příloh → jeden blob store** (globální dedup přes SHA-256, vše přes `seaweed_store.py`):
  1. mailstore: `mailstore/mailstore_attachments_poc.py` (běží z toweru .76), zapisuje pole `seaweed_attachments[]` do mail dokumentů v Mongo `emaily`.
  2. Graph pipeline: `3_download_attachments_v1.5.py` při uložení nové přílohy zároveň pushne do SeaweedFS; do `emaily.attachments_index` (dedup dle SHA-256=_id) zapíše `seaweed_path/seaweed_url/seaweed_synced_at`. Jednorázový backfill: `seaweed_attachments_backfill_graph.py` (čte `/mnt/Emails/<mbox>/Attachments/`).
  3. JNJ pipeline (vbuzalka@its.jnj.com, viz [[python-runner]]/[[graph-email-import]]): `EmailsImport/jnj_tower_ingest_v1.3.py` při parse `.msg` z `/mnt/JNJEMAILS` nahraje binárku přílohy do SeaweedFS, do `attachments[]` v mail doc zapíše `sha256/seaweed_path/seaweed_url` + doc-level `seaweed_synced_at`. Jednorázový backfill: `EmailsImport/seaweed_attachments_backfill_jnj.py` (znovuotevře `.msg` přes importlib reuse `open_message`+`extract_attachments`).
  Disk/.msg zůstávají paralelně. Viz [[project-mailstore]] a [[project-python-runner]].
- Bloby: share `SeaweedFS` → `/mnt/user/SeaweedFS/data`, array disk9–11 pod paritou (useCache=no). Filer leveldb + master raft: `/mnt/cache2tb0225dec/appdata/seaweedfs/` (SSD, bez parity).
- Noční backup filer metadat: cron 03:30 na Tower1 (`/boot/config/plugins/dynamix/seaweedfs-backup.cron`) spouští `/boot/config/scripts/seaweedfs_meta_backup.sh` — `fs.meta.save` přes weed shell → scp na tower 192.168.1.76 do `/mnt/user/Backup/Critical/SeaweedFS/daily/` (drží 7), neděle navíc `weekly/` (drží 4). Log `/var/log/seaweedfs_backup.log`. Restore: `fs.meta.load`.
- Tower (.76, root heslo 7309208104) a Tower1 mají vyměněné SSH klíče — z Tower1 na tower jde psát přímo.
- **HW závada (2026-06, přetrvává od 26.5.):** SATA řadič/port `ata1` na Tower1 „lost interrupt (Status 0x50)" → kernel `Disabling IRQ #19`, ovladač spadne do pollingu, link degraduje na 1.5 Gbps. Na `ata1` visí **disk10 (sdj) a disk11 (sdk)** — obě TOSHIBA MG08ACA16TE (zbytek pole Seagate). Tyto dva disky pak čtou ~20–40 KB/s (iostat: 100% util, r_await 200–400 ms), `mdunraidd11` v D-state, iowait ~97 %. SMART obou PASSED (problém je řadič/kabel, ne ploténky). **Důsledek:** SeaweedFS bloby na disk9–11 se z disk10/11 čtou na ~0,2 MB/s → velké soubory (EUNI videa) se prakticky nestáhnou. Fix: reboot (povolí IRQ) jako dočasný, trvale přepojit obě Toshiby kabelem na jiný port/HBA než `ata1`.
- Pozor: Unraid flash `/boot` je VFAT (case-insensitive) — share cfg `seaweedfs.cfg` vs `SeaweedFS.cfg` je tentýž soubor. Share nastavení za běhu mění `emcmd "query&string"` (jeden argument, nutné `shareNameOrig` + `cmdEditShare=Apply`), live stav v `/var/local/emhttp/shares.ini`.