cf and pf are stored separately.
For pf is not efficient to do: HDATE = 20040101/20040106/20040111/20040116/20040121/20040126/20040201/20040206/20040211/20040216/20040221/20040226/20040301/20040306/20040311/20040316/20040321/20040326/20040401/20040406/20040411/20040416/20040421/20040426/20040501/20040506/20040511/20040516/20040521/20040526/20040601/20040606/20040611/20040616/20040621/20040626/20040701/20040706/20040711/20040716/20040721/20040726/20040801/20040806/20040811/20040816/20040821/20040826/20040901/20040906/20040911/20040916/20040921/20040926/20041001/20041006/20041011/20041016/20041021/20041026/20041101/20041106/20041111/20041116/20041121/20041126/20041201/20041206/20041211/20041216/20041221/20041226, NUMBER = 1,
but it is more efficient to group all members in one go for fewer dates: HDATE = 20040101/20040106/20040111/20040116/20040121/20040126, NUMBER = 1/to/50 This implies less positioning and more contiguous reads.
We could look at increasing the 10GB limit. We have more hardware and are in a better position to handle bigger chunks.
For the 3 allowed streams, I would extract different type/levtype in different streams. For instance: a) 1 stream: pf/sfc b) 1 stream: pf/pl c) 1 stream: cf/sfc and when it finishes,cf/pl and I would put 2 requests for each stream above. Once a request finishes and starts the downloading, the next request will kick in, and it will find in many cases that the tape volume is still in the tape drive, which will save in avg 2 minutes for a tape mount.
|