janssen/claude-memory/project_seaweedfs.md

name, description, metadata

name	description	metadata
project-seaweedfs	SeaweedFS na Tower1 (192.168.1.50) — kontejner, rozdělení dat, noční backup filer metadat na tower .76	node_type type originSessionId memory project 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.