JuiceFS S3 cache для Mac mini M4
матрица метаданных, rsync и OpenClaw

Где появляется риск в параллельном Mac-кластере

1. Метаданные. JuiceFS хранит данные в S3, но операции lookup, rename и lock проходят через отдельный движок метаданных. Для десятков Xcode jobs Redis быстрый, но требует строгого backup; PostgreSQL медленнее на пике, зато проще для аудита и репликации.

2. Клиентский cache-dir. Если положить cache рядом с DerivedData, сборка и файловая система начинают конкурировать за APFS. На Mac mini M4 лучше выделить отдельный каталог, например /Volumes/cache/juicefs, и заранее задать порог очистки.

3. Артефакты и rsync. Без --bwlimit один promote может забрать канал у canary-узла. Для межрегионального трафика артефакты нужно отправлять после build lock, с --partial, --delete-delay и ограниченным числом параллельных задач.

Матрица выбора: metadata engine, S3 и cache

Ключевые параметры juicefs format и mount

Базовый формат для S3-совместимого хранилища держите воспроизводимым: juicefs format --storage s3 --bucket https://s3.example.com/mac-artifacts --access-key ... --secret-key ... redis://meta:6379/1 macci. Для PostgreSQL меняется только metadata URL: postgres://juicefs:***@pg/meta?sslmode=require. Имя volume фиксируйте в runbook, иначе OpenClaw и CI будут спорить о namespace.

Mount на каждом Mac mini M4: juicefs mount macci /mnt/artifacts --cache-dir /Volumes/cache/juicefs --cache-size 300000 --buffer-size 512 --max-uploads 8 --max-deletes 4 --prefetch 2. Для узлов 2 ТБ можно поднять cache-size до 700000–900000 МБ и max-uploads до 12, если S3 отвечает стабильно. Writeback включайте только там, где потеря узла не оставит незалитые артефакты.

Пять шагов внедрения с лимитом rsync

• Разведите роли. Один canary Mac mini M4 получает новый mount, остальные читают прежний путь до прохождения проб.
• Зафиксируйте lock. Promote артефакта выполняется через flock /var/lock/artifacts.lock, чтобы JuiceFS upload и rsync не писали один релиз одновременно.
• Ограничьте rsync. Для межрегиональной синхронизации используйте rsync -az --partial --delete-delay --bwlimit=60000; для ночного окна 2 ТБ узла допустимо 90000–120000 КБ/с.
• Разделите cache. /Volumes/cache/juicefs не должен находиться в том же дереве, где Xcode чистит DerivedData и Simulator runtime.
• Публикуйте digest. OpenClaw canary probe пишет статус mount, cache usage, p95 metadata и код последнего webhook в один JSON, а не в россыпь логов.

Чек-лист 1 ТБ/2 ТБ и OpenClaw canary

• 1 ТБ: warning при 700 ГБ занято, cleanup при 820 ГБ, hard stop новых jobs при 900 ГБ; cache-size держите 300–600 ГБ.
• 2 ТБ: warning при 1.4 ТБ, cleanup при 1.65 ТБ, hard stop при 1.8 ТБ; cache-size 700–900 ГБ, если S3 egress предсказуем.
• Canary probe: каждые 60 секунд проверяйте mountpoint, запись 16 МБ файла, удаление, latency metadata и свободный объём APFS.
• Webhook digest: при ошибке OpenClaw отправляет краткую сводку: region, node, mount state, last rsync exit, cache usage, waterline и ссылку на runbook.

Отдельно зафиксируйте границу отката. Если p95 metadata держится выше 40 мс две проверки подряд, canary снимается с балансировки, mount переводится в read-only сценарий, а новые jobs возвращаются на прежний артефактный путь. Если S3 даёт 5xx, OpenClaw не должен ретраить бесконечно: достаточно трёх попыток с jitter, затем один digest в общий канал и ссылка на последнюю успешную ревизию.

Для аудита храните рядом три файла: версию JuiceFS client, параметры mount и снимок waterline перед promote. Такая связка помогает отличить проблему движка метаданных от переполненного cache-dir или агрессивного rsync. В многоузловой схеме это важнее, чем абсолютная скорость: дежурный видит, какой регион деградировал, какой node ещё безопасен для сборки и где можно вручную повторить синхронизацию без риска затереть рабочий артефакт.

Для смежных решений полезны внутренние разборы: SeaweedFS и rsync, Nomad affinity и build lock, а также OpenClaw logs webhook. Они закрывают альтернативы, если JuiceFS оказывается слишком сложным для текущей команды.