MarFS provides a scalable near-POSIX file system by using one or more POSIX file systems as a scalable metadata component and one or more data stores (object, file, etc) as a scalable data component.
Other
96
stars
27
forks
source link
use repo.latency (or some new field) to control read/write time-outs #93
I think maybe the original intent of this config-field was to record how long could be expected for a repo to be brought online, if it was currently online. Maybe the field should be preserved for that case (which we do not deal with at all, for now). If so, then we could create a different field to do the thing I'm proposing:
There should probably be one or more per-repo fields in the config that allow admins to control the timeouts that are applied by marfs internals, for reads and writes. This would avoid us having to patch the system, if we discover problems with the hardcoded values (currently 20 sec), or want to experiment. Perhaps different timeouts for read vs. write?
I think maybe the original intent of this config-field was to record how long could be expected for a repo to be brought online, if it was currently online. Maybe the field should be preserved for that case (which we do not deal with at all, for now). If so, then we could create a different field to do the thing I'm proposing:
There should probably be one or more per-repo fields in the config that allow admins to control the timeouts that are applied by marfs internals, for reads and writes. This would avoid us having to patch the system, if we discover problems with the hardcoded values (currently 20 sec), or want to experiment. Perhaps different timeouts for read vs. write?