Hi All,
I’m new to CTA so I apologise in advance if my question seems silly…
We’ve come across something a little strange and I am not sure if it is a bug or a feature (and/or I am just doing it wrong).
In EOS we tend to use linked attributes for a lot of things, so we create a dummy directory, set a bunch of attributes to it and then link that to other directories within EOS.
It seems CTA Frontend ignores some of this and its error:
LVL="ERROR" PID="1" TID="204" MSG="In RequestProc::ExecuteAction(): RSP_ERR_PROTOBUF: processCREATE: sys.archive.storage_class extended attribute is not set"
Doing an attr ls on the folder I can see the linked attribute sys.link.archive.storage_class="single-copy-backup"
To resolve this I manually attr set sys.archive.storage_class=single-copy-backup and it works.
Is this a bug or a feature? Is it possible for CTA to look at sys.link.archive.storage_class if sys.archive.storage_class is not set?
Cheers
Michael
Hi Michael,
I believe that this is indeed a bug. We have never tried using linked attributes to set the tape storage class but I would have expected it to work. I have therefore created the following CTA gitlab issue:
Regards,
Steve
Sorry for the long delay in responding. We had to discuss your use case internally to decide if this was a feature or a bug!
At CERN, we link extended attributes for the workflows, but never for storage classes. This is because the workflows are the same for all directories, but storage classes change from one part of the directory tree to another. We do not propose to change this as it would hide the consequences of changing the storage class in the directory being linked from (i.e. it would open up the possibility of inadvertently setting or changing the storage class in an undesired way).
In other words: linked storage classes are not supported, as a matter of policy.
When setting up the directories in CTA, you can set the default storage class at the top level, this will then be inherited by all directories underneath at directory creation time.