Usage & Limitations of Shared Storage
Once a Shared Storage is connected to a runtime service, Zerops will create a new folder /mnt/[shared storage name] in the runtime service's filesystem.
For example, /mnt/teststorage for a teststorage Shared Storage:
Note
The content of this folder is shared among all containers of the connected runtime service.
If you connect multiple runtimes, the content of the folder will be shared among all containers of these services.
Mount Points and Multiple Volumes​
- Multiple storage volumes can be mounted to a single service (e.g.,
/mnt/files1,/mnt/files2, etc.) - Shared storage mount is only available in runtime containers, not during build and prepare runtime phases
- All filesystem operations are automatically logged to runtime logs
For technical details about mount behavior and filesystem capabilities, see the Technical Details page.
Use Cases​
Shared Storage is ideal for:
- Persistent filesystem-based databases: SQLite, Prometheus DB, etc.
- Configuration sharing: Deploy configurations once and share across multiple services
- Example: Deploy Apache Airflow configurations and DAG files once and share with all worker nodes
- Alternative to object storage: For applications that require filesystem semantics rather than object storage
- Application data: Store and serve images, documents, and other assets
Performance Considerations​
When using Shared Storage, keep in mind:
- For write-heavy workloads, consider batching operations
- Minimize operations with many small files for better performance
For more detailed information about performance constraints and limitations, see the Technical Details page.
Troubleshooting​
Common Issues​
- The
dfcommand may show incorrect or misleading information when used with shared storage mounts. Please refer to the Zerops GUI for accurate storage metrics.