Commit 5a2699dd authored by Giuseppe Lo Presti's avatar Giuseppe Lo Presti
Browse files

[migration] Described the new behavior concerning dual copy tape pools

parent 7bddb273
......@@ -26,7 +26,8 @@ The tools are designed to work as follows, for any given VO:
Alternatively, for a test import without blocking access to CASTOR, import all relevant directories one by one using `eos-import-dirs`. Example:
* `eos-import-dirs /atlas`
* `eos-import-dirs /grid/atlas`
[warning] The list of "relevant" directories for a given VO is to be provided by the operator. No automatic heuristic is provided for this step.
> [warning] The list of "relevant" directories for a given VO is to be provided by the operator. No automatic heuristic is provided for this step.
2. For each VO's tapepool: perform the tapepool export using `export_production_tapepool_to_cta.sh`. Example:
* `bash export_production_tapepool_to_cta.sh r_atlas_raw atlas eosctaatlas --doit`
......@@ -34,9 +35,9 @@ The tools are designed to work as follows, for any given VO:
3. In case of errors, `export_production_tapepool_to_cta.sh` stops and the operator is expected to fix the case and rerun the export, possibly re-executing by hand one of the commands documented above. Errors are accumulated in suitable Oracle tables both for the database migration and the EOS namespace injection tools. For the latter, please refer to their specific instructions.
[warning] In order to efficiently import tape pools holding dual tape copies and avoid a double pass over the EOS metadata import, dual copy files must be imported in order, i.e. tape pools holding 1st copies must be imported prior to tape pools holding 2nd copies. To protect CTA, the `tapepool_castor_to_cta.py` tool will abort if that's not the case, or if some files are found having their 1st tape copy and other files having their 2nd tape copy, all in the given tape pool.
> [warning] In order to efficiently import tape pools holding dual tape copies, and avoid a double pass over the EOS metadata import, such tape pools are imported in a single operation: assuming that a tape pool holding the 1st copies is requested to be exported, the corresponding tape pool holding the 2nd copies is **also exported**. Furthermore, to protect CTA, `tapepool_castor_to_cta.py` will abort if some files are found having their 1st tape copy and other files having their 2nd tape copy, all in the given tape pool.
In addition, the following tools are provided, which can be used as part of a restore/recovery procedure. Such procedure has deliberately **not** been automated and will have to be dealt with on a case by case basis.
* `vmgr_reenable_tapepool.sh`: reverts in CASTOR the export of a tapepool, which had been successfully exported to CTA. All related tapes are marked `FULL`.
* `cta-catalogue-remove-castor-tapes.py`: removes in the CTA catalogue all metadata related to CASTOR tapes for a given tapepool. If additional CTA tapes were added to the tapepool, they are left in the catalogue.
* `cta-catalogue-remove-castor-tapes.py`: removes in the CTA catalogue all metadata related to CASTOR tapes for a given tapepool. If additional CTA tapes were added to the tapepool, they are left in the catalogue. If the tapepool concerns dual tape copies, metadata related to the other copies is **also removed**.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment