1 2-define(SECOND, 1000). 3-define(MINUTE, (60 * ?SECOND)). 4-define(HOUR, (60 * ?MINUTE)). 5-define(DAY, (24 * ?HOUR)). 6-define(MB, (1024 * 1024)). 7 8% Maximum length of tag/blob prefix 9-define(NAME_MAX, 511). 10 11% How long ddfs node startup can take. The most time-consuming part 12% is the scanning of the tag objects in the node's DDFS volumes. 13-define(NODE_STARTUP, (1 * ?MINUTE)). 14 15% How long to wait on the master for replies from nodes. 16-define(NODE_TIMEOUT, (10 * ?SECOND)). 17 18% How long to wait for a reply from an operation coordinated by the 19% master that accesses nodes. This value should be larger than 20% NODE_TIMEOUT. 21-define(NODEOP_TIMEOUT, (1 * ?MINUTE)). 22 23% The minimum amount of free space a node must have, to be considered 24% a primary candidate host for a new blob. 25-define(MIN_FREE_SPACE, (1024 * ?MB)). 26 27% The maximum number of active HTTP connections on a system (this 28% applies separately for GET and PUT operations). 29-define(HTTP_MAX_ACTIVE, 3). 30 31% The maximum number of waiting HTTP connections to queue up on a busy system. 32-define(HTTP_QUEUE_LENGTH, 100). 33 34% The maximum number of simultaneous HTTP connections. Note that 35% HTTP_MAX_CONNS * 2 * 2 + 32 < Maximum number of file descriptors, where 36% 2 = Get and put, 2 = two FDs required for each connection (connection 37% itself + a file it accesses), 32 = a guess how many extra fds is needed. 38-define(HTTP_MAX_CONNS, 128). 39 40% How long to keep a PUT request in queue if the system is busy. 41-define(PUT_WAIT_TIMEOUT, (1 * ?MINUTE)). 42 43% How long to keep a GET request in queue if the system is busy. 44-define(GET_WAIT_TIMEOUT, (1 * ?MINUTE)). 45 46% An unused loaded tag expires in TAG_EXPIRES milliseconds. Note that 47% if TAG_EXPIRES is not smaller than GC_INTERVAL, tags will never 48% expire from the memory cache and will always take up memory. 49-define(TAG_EXPIRES, (10 * ?HOUR)). 50 51% How often the master's cache of all known tag names is refreshed. 52% This refresh is only needed to purge deleted tags eventually from 53% the tag cache. It doesn't harm to have a long interval. 54-define(TAG_CACHE_INTERVAL, (10 * ?MINUTE)). 55 56% How soon a tag object initialized in memory expires if it's content 57% cannot be fetched from the cluster. 58-define(TAG_EXPIRES_ONERROR, (1 * ?SECOND)). 59 60% How often a DDFS node should refresh its tag cache from disk. 61-define(FIND_TAGS_INTERVAL, ?DAY). 62 63% How often buffered (delayed) updates to a tag need to be 64% flushed. Tradeoff: The longer the interval, the more updates are 65% bundled in a single commit. On the other hand, in the worst case 66% the requester has to wait for the full interval before getting a 67% reply. A long interval also increases the likelihood that the server 68% crashes before the commit has finished successfully, making requests 69% more unreliable. 70-define(DELAYED_FLUSH_INTERVAL, (1 * ?SECOND)). 71 72% How long to wait between garbage collection runs. 73-define(GC_INTERVAL, ?DAY). 74 75% Max duration for a GC run. This should be smaller than 76% min(ORPHANED_{BLOB,TAG}_EXPIRES). 77-define(GC_MAX_DURATION, (3 * ?DAY)). 78 79% How long to wait after startup for cluster to stabilize before 80% starting the first GC run. 81-define(GC_DEFAULT_INITIAL_WAIT, (5 * ?MINUTE)). 82 83% The longest potential interval between messages in the GC protocol; 84% used to ensure GC makes forward progress. This can be set to the 85% estimated time to traverse all the volumes on a DDFS node. 86-define(GC_PROGRESS_INTERVAL, (30 * ?MINUTE)). 87 88% Number of extra replicas (i.e. lost replicas recovered during GC) to 89% allow before deleting extra replicas. 90-define(NUM_EXTRA_REPLICAS, 1). 91 92% Permissions for files backing blobs and tags. 93-define(FILE_MODE, 8#00400). 94 95% How often to check available disk space in ddfs_node. 96-define(DISKSPACE_INTERVAL, (10 * ?SECOND)). 97 98% The maximum size of payloads of HTTP requests to the /ddfs/tag/ 99% prefix. 100-define(MAX_TAG_BODY_SIZE, (512 * ?MB)). 101 102% Tag attribute names and values have a limited size, and there 103% can be only a limited number of them. 104-define(MAX_TAG_ATTRIB_NAME_SIZE, 1024). 105-define(MAX_TAG_ATTRIB_VALUE_SIZE, 1024). 106-define(MAX_NUM_TAG_ATTRIBS, 1000). 107 108% How long HTTP requests that perform tag updates should wait to 109% finish (a long time). 110-define(TAG_UPDATE_TIMEOUT, ?DAY). 111 112% Timeout for re-replicating a single blob over HTTP PUT. This 113% depends on the largest blobs hosted by DDFS, and the speed of the 114% cluster network. 115-define(GC_PUT_TIMEOUT, (180 * ?MINUTE)). 116 117% Delete !partial files after this many milliseconds. 118-define(PARTIAL_EXPIRES, ?DAY). 119 120% When orphaned blob can be deleted. This should be large enough that 121% you can upload all the new blobs of a tag and perform the tag update 122% within this time. 123-define(ORPHANED_BLOB_EXPIRES, (5 * ?DAY)). 124 125% When orphaned tag can be deleted. 126-define(ORPHANED_TAG_EXPIRES, (5 * ?DAY)). 127 128% How long a tag has to stay on the deleted list before 129% we can permanently forget it, after all known instances 130% of the tag object have been removed. This quarantine period 131% ensures that a node that was temporarily unavailable 132% and reactivates can't resurrect deleted tags. You 133% must ensure that all temporarily inactive nodes 134% are reactivated (or cleaned) within the ?DELETED_TAG_EXPIRES 135% time frame. 136% 137% This value _must_ be larger than the other time-related DDFS 138% parameters listed in this file. In particular, it must be larger 139% than ORPHANED_TAG_EXPIRES. 140-define(DELETED_TAG_EXPIRES, (30 * ?DAY)). 141 142% How many times a tag operation should be retried before aborting. 143-define(MAX_TAG_OP_RETRIES, 3). 144 145% How long to wait before timing out a tag retrieval. This should be 146% large enough to read a large tag object off the disk and send it 147% over the network. 148-define(GET_TAG_TIMEOUT, (5 * ?MINUTE)). 149