@@ -57,4 +57,18 @@ umount /srv && mount -o fsc /srv # remount не работает!
...
@@ -57,4 +57,18 @@ umount /srv && mount -o fsc /srv # remount не работает!
## Changelog
## Changelog
(пока нет записей)
### 2026-07-18 — медленные метаданные `/srv` на builder64
-`/srv` экспортируется с `aspetos` из ZFS `ssd1/srv` (mirror: Crucial MX500 + Samsung 870 QVO), не из NVMe `pool0`.
- Локальный `git status --porcelain --untracked-files=no` в `/srv/lav/Projects/git-eter/etersoft-admin-essential` на aspetos: **25 ms** (`refresh index` 12.7 ms). Через NFS на builder64: **15–21 s**, из них `refresh index` 19.6 s.
- Во время запуска на builder64 `GETATTR` получал ответ сервера примерно за 0.22 ms, но ждал в клиентской NFS RPC-очереди около 64 ms на запрос; `ACCESS`/`LOOKUP` ждали 89–93 ms. Это клиентская перегрузка очереди RPC/слотов, а не задержка ZFS, SATA или сети.
-`zpool status -v ssd1`: без ошибок; SMART обоих SSD passed, uncorrectable/pending/reallocated = 0; в момент измерений диск не был загружен.
- Синхронная проверка 2026-07-18: на aspetos CPU idle 67–74%, iowait 0–1%, `ssd1` ~80–84 IOPS и <1.1 MB/s; nfsd не насыщен. Серверная сторона не является узким местом.
- Возможная причина высокого клиентского backlog: на сервере включены NFSv4 delegations (`fs.leases-enable=1`), а `TEST_STATEID` растёт аномально быстро (18 885 за 10 s на aspetos; на builder64 в отдельном интервале — 96 668 за 10 s). Есть известная старая Linux NFSv4 проблема с делегациями и избытком `TEST_STATEID`; для текущих ядер 6.12.68/6.12.74 совпадение симптомов ещё не доказывает ту же bug. Не отключать delegations без согласованного окна: потребуется перезапуск NFS и контрольный замер.
### Подтверждённый workaround — 2026-07-18
- В согласованное окно на `aspetos` временно выполнены `fs.leases-enable=0` и `serv nfs-server restart`; перезапуск прошёл успешно.
- После этого на builder64 `TEST_STATEID` = **0 за 10 s**. Контроль от владельца дерева `lav`: `git status --porcelain --untracked-files=no` — **33.8 ms**, `refresh index` — **27.8 ms** (до изменения 15–21 s / 19.6 s соответственно).
- Следовательно, первопричина тормозов `/srv` — NFSv4 delegations (`TEST_STATEID` storm), не ZFS, SATA или nfsd. Состояние **временно**: `fs.leases-enable=0` не сохранён в sysctl-конфигурации и исчезнет после перезагрузки. Закреплять только по отдельному решению.
- Контроль `/home` на builder64 после отключения delegations: `/home` = `homeserver:/home`, NFSv4.2 от aspetos; обход первых 1 000 файлов от `lav` — **128 ms**, `TEST_STATEID` = **0 за 10 s**. Отдельная настройка `/home` не требуется: `fs.leases-enable` действует на все NFSv4-экспорты server-а.
3.`eterban_switcher.py` (main daemon in `eterban.service`) listens Redis pubsub and executes `ipset -A/-D`
4. Auto-unban: background thread in switcher checks `AutoBanManager` schedule, publishes to `unban` when ban period expires
**Why unban may fail**: if `eterban.service` is not running or not subscribed to Redis, `unban.py` silently succeeds (publish returns 0 subscribers) but ipset is NOT modified. Always verify with `eterban search` after unban.
**iptables rules** (created by switcher on startup):
- WAN interfaces: DNAT src from `eterban_1` to ban_server (91.232.225.67)
- WAN interfaces: REJECT FORWARD from `eterban_1` except ports 80,81,443
- Internal interface: DNAT dst from `eterban_1` ports 80,443 to ban_server:82
## Ban pages
## Ban pages
- External (banned IP → our sites): http://91.232.225.67/ (port 80/81)
- External (banned IP → our sites): http://91.232.225.67/ (port 80/81)
Все важные сведения по инфраструктуре записывай в `.claude/docs/` — файлы в репозитории, доступные всем. Заметки в session memory — только для текущей работы, не для долгосрочных справок.
### Память проекта (`.claude/memory/`)
**Основная база знаний проекта.** Перед ответом на вопросы про инфраструктуру — ищи сначала туда (`grep`/`read` по `.claude/memory/`). Новые заметки, уроки и справочники пиши туда же. Структура:
