Administration
Common operations:
- Initialize Instance
- Reconfigure
- Remove Instance
- Add New Instance
- Shared Mount Across Nodes
- PITR Recovery
- Troubleshooting
- Performance Tuning
See FAQ for more.
Initialize Instance
Initialization steps:
- Install
juicefspackage - Create shared cache dir (default
/data/juice) - Run
juicefs format --no-update(only effective on first creation) - Create mount point and set permissions
- Render systemd unit and env files
- Start service and wait for metrics port
- Register to VictoriaMetrics (if infra node exists)
Reconfigure
After changing config, it’s recommended to run (update config and ensure service is online):
Render config without touching service state:
Notes:
juice_config,juice_launchensures service isstarted, but does not force-restart an already running instancedataonly takes effect on the firstformat- After changing
mountoptions, manually restart the instance service (systemctl restart juicefs-<name>)
Remove Instance
- Set instance
statetoabsent - Run
juice_clean
Removal actions:
- Stop systemd service
umount -llazy unmount- Remove unit and env files
- Reload systemd
- Rewrite this node’s VictoriaMetrics target file, removing instances with
state=absent
PostgreSQL metadata, PostgreSQL jfs_blob data tables, and object-storage data are not deleted.
Running only -t juice_clean does not update monitoring targets and temporarily leaves stale scrape endpoints for removed instances. The commands above therefore run juice_register as well.
Add New Instance
Add a new instance in config, ensure unique port:
Deploy:
Shared Mount Across Nodes
Configure the same meta and instance name on multiple nodes:
Only one node needs to format the filesystem; others will skip via --no-update.
PITR Recovery
JuiceFS metadata and data must be restored to a mutually consistent state. Before any restore, stop every writer and unmount/stop the corresponding JuiceFS service on every client, identify the exact PostgreSQL cluster and target time, and confirm an available backup:
Only after confirming the exact cluster name, a recent backup, the recovery target, and a rollback plan should you follow the PostgreSQL PITR tutorial to stop Patroni/PostgreSQL and perform the restore. pg-pitr does not stop services, repair Patroni/DCS, validate data, or rebuild replicas; the command above is not a complete recovery procedure.
If metadata and the --storage postgres jfs_blob table are in the same restored PostgreSQL database, database PITR can return both to one point in time. If they reside in different databases or clusters, design a coordinated recovery point for both.
If file data is in Silo/S3, PostgreSQL PITR rolls back metadata only, not objects. Newer objects may remain, while old objects that were deleted or collected may be unavailable. Recoverability depends on object versioning, trash, and lifecycle policies; do not run garbage collection until validation is complete.
Troubleshooting
Mount Fails
Metadata Connection Issues
Metrics Port Check
Performance Tuning
Pass juicefs mount options via mount:
Key metrics to watch:
juicefs_blockcache_hits/juicefs_blockcache_miss: cache hit ratiojuicefs_object_request_durations_histogram_seconds: object storage latencyjuicefs_transaction_durations_histogram_seconds: metadata transaction latency