Limit the number of repack sub-requests that can be expanded at the same moment
Problem
At the moment, a repack request will be fully expanded into all it's retrieve/archive sub-requests, regardless of the number of files in the tape.
For small tapes this is not a problem. However, for tapes with several 100K's or 1000K's of files, this will result into massive repack request objects, with over 100MB of size (about 100MB for every 1 million files).
These massive objects push the object store backend to the limit (due to the constant fetching and commiting), which has various problems in production:
- https://gitlab.cern.ch/cta/operations/-/issues/1234
- https://gitlab.cern.ch/cta/operations/-/issues/1258
- #545 (closed)
Proposed (temporary) solution
A possible solution for this problem is to limit the number of sub-request that can be expanded at a single moment. This will, as a consequence, put an upper limit on the maximum size that the repack request objects can achieve.
If the repack request has not covered all files, it can always be resubmitted again by an operator tool.