You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The temp folder path where active uploads to the node and objects being fetched by sync worker from other nodes is not configurable, but is always created as a sub folder under the uploads directory (long term storage of data objects).
Some ideas for scaling storage capacity of the node will require separation of temp files from the long term storage path. If we decide to use object storage (s3 compatible) then its not possible to store incomplete download files there.
Solution
Add new parameter to server command to specify a fully qualified path for the temp folder to use.
Challenges ?
Typically the path to the uploads folder will be on a volume with considerable capacity, and this volume might be mounted from a network storage cluster. It might be more suitable for the temp folder to be a path on the local host file system with not as much disk capacity. Should the node actively try to manage the number of downloads and uploads at a rate that takes the temp folder size into consideration?
The text was updated successfully, but these errors were encountered:
Background
The temp folder path where active uploads to the node and objects being fetched by sync worker from other nodes is not configurable, but is always created as a sub folder under the uploads directory (long term storage of data objects).
Some ideas for scaling storage capacity of the node will require separation of temp files from the long term storage path. If we decide to use object storage (s3 compatible) then its not possible to store incomplete download files there.
Solution
Add new parameter to
server
command to specify a fully qualified path for the temp folder to use.Challenges ?
Typically the path to the uploads folder will be on a volume with considerable capacity, and this volume might be mounted from a network storage cluster. It might be more suitable for the temp folder to be a path on the local host file system with not as much disk capacity. Should the node actively try to manage the number of downloads and uploads at a rate that takes the temp folder size into consideration?
The text was updated successfully, but these errors were encountered: