I am really not sure how this happened but we have a few tapes (in our Tier-1 tape library) from an ATLAS tape pool which contain files from two different EOS namespaces (that are hosted in two diffrent EOS instances). In particular, these tapes contain files that have either this path
/eos/antares/prod/atlas/raw/atlasdatatape/…
or this path
/eos/antaresfac/prod/storaged_dls/dls/container
Now, the later files are normally stored in another tape library (our Facilities one). I confirmed that a prepare request for one of these files (/eos/antaresfac/prod/storaged_dls/dls/container), resulted in a mount in the Tier-1 tape lib. This is expected as both of our tape libs are controlled by CTA and they don’t care from which EOS instance the prepare request is coming from.
I know how to repack the ATLAS files to another Tier-1 tape pool (I want to get rid of the one the current one called atlinapp) by doing
Obviously, the Facilities files ( /eos/antaresfac/prod/storaged_dls/dls/container/… ) will fail to be moved,
Assuming the storage class of the destination pool has been assigned to each set of files,
is it then possible to repack these files to the Facilties tape library by doing
Hello George,
repack works independently of the eos path files of the files stored on tape and repack url is just the location of temporary repack files.
Basically repack just creates a directory with the tape name in repack buffer url location and tape file 1 is file 1 there and so on…
What you need to do is to change the storage class of the files, propagate this to the tape side and then repack will queue the files for T1 storage class to the target tapepool of the archive route defined for this storage class.
If you do not change propagate the storage class to the tape files on that tape, repack cannot sort it for you.
Presentation pdf and recording is available, but currently running the full chain is a bit tricky.
I guess this should wait for some polishing on our side: in theory this kind of metadata mixing should not cause any operation issue.
We have similar metadata work ongoing at CERN as we need to logically split large storage classes/tapepools and we’ll come back to this problematic later.
Many thanks for the reply and for pointing to the talk.
Both sets of files that I mentioned above are in the right (i.e. desired) EOS instance/namespace; it just that some of them are not in the “appropriate” tapes/library: the /eos/antaresfac/prod/storaged_dls/dls/container are in Tier-1 instead of Facilities library tapes.
I will make sure that all the files are assigned to the desired storage class - both on EOS and on the CTA Catalogue - and then a repack will hopefully seperate them. Hopefully this is not too invasive or dangerous