I - FAQ
There is a lot of bits of documentation spread through forum answers or lost documentation. Sometimes it is just information that it is assumed you know, or that you just simply obtain with experience. I will be gathering all I found useful here and hope it can make your CTA journey easier!
Concepts
Parameters
ObjectStore
What's the logic behind the names of the objects I see inside the ObjectStore?
You'll see two types of objects. The ones corresponding to processes, follow this pattern to generate its name:
The objects created by these processes are named following this pattern:
Scheduling
How does CTA manage the requests in queue?
The CTA Scheduler divides the requests (or objects) that has in the OStoreDB in two queues by their type: the ArchiveRequestQueue and the RetrieveRequestQueue.
What is "the CTA scheduler"?
CTA has an scheduling algorithm that called scheduler. Every ten seconds, this fella checks the requests on queue, filters them and does a selection of what we call "potential mounts".
Ok, once the requests are queued, how does the scheduler do the scheduling process in order to decide which requests are potential mounts and finally trigger a mount?
The Scheduler will be constantly filtering the requests through three filter parameters + 1 priority parameter. These consist in:
1. The minimum amount of bytes or files on queue to guarantee a mount. This is defined by the parameter taped MountCriteria of cta-taped daemon config file (/etc/cta/cta-taped.conf). Once this amount is exceeded, CTA will inmediately try to mount and process the requests if possible, even if those requests were supposed to wait for a little longer on queue. Default is 500GB and 10000 files.
2. The minimum age in seconds that a request must be on its queue before it is considered a potential mount. Once the minimum age is surpassed, CTA will manage the request, but not before. We as CTA administrators can define how long do we want a file to wait before it is considered as a potential mount just by tunning the parameters --minarchiverequestage/--aa and --minretrieverequestage/--ra of the mount policies. (See: Setting up mount policies).
3. The maximum drives allocated by vo. When creating an vo, we set a maximum number of drives for reading and for writing operations with the parameters --readmaxdrives/--rmd and --writemaxdrives/--wmd.
4. The priority parameter for archives and retrieves specified on the mount policy (--archivepriority/--apand --retrievepriority/--rp parameters). Higher value means higher priority.
Suppose that after all those filters there is a tie between two requests. How does the Scheduler decide which one goes first then?
First, the scheduler would look at the mount type of the requests (are they archives or retrieves?). CTA by default gives priority to archiving operations, so given the case that after all those 3 scheduling filters+ 1 priority filter the tie is an archive request vs a retrieve request, CTA will try to manage the archive first. If tied requests are the same type, the scheduler will look at the oldest job of them all and finally pick that one and so on.
So, CTA prioritizes archive over retrieve operations?
By default, yes. That means that if two or more requests are elegible for potential mounts, CTA will prioritise the archives. However, this shouldn't be a problem as we can set the priority of each mount type through mount policies.
I didn't understand anything.
You can always check this presentation: "A brief overview of the CTA mount scheduling logic" by Cedric Caffy, specially at minutes 14:30 to 17:50.
Organizing files & Repacking
Can I change the logfile of the cta-frontend-grpc? I don't want it on
/var/log/messages.
Yes, you can always do an rsyslog rule. Go to /etc/rsyslog.d/ and create a new rule (either in a new file or at 00_client.conf). The rule must look like this:
Can I change the original storage class of a file for a new one?
Yes, this operation has an specific tool called
cta-change-storage-classand it comes with the cta-cli package. It has its own manpage, but to sum up:
Is there a way to repack files from one tapepool to another even if they have different storage classes? Short answer is yes, now you're able to! You previously have to change the storage class of the files you desire to move with the tool cta-change-storage-class.
Drives and compression
Can CTA manage file compression before writting to tape?
No, there isn't any compression options at CTA's level. Compression is performed on the hardware layer (your tape drives) during archival. Note that LTO8 drives come with compression enabled by default. You can check or change your drive compression settings either on the library side or at the SCSI level. (See: Tape drives compression settings)
How does the tape drive compression work then?
Data compression works by using a mathematical algorithm that reduces redundant strings of data. For tape drives, the compression algorithm is typically implemented in hardware and will remove redundancy from data by encoding patterns of input characters more efficiently. The more repeat patterns in the data, the more the data can be compressed. Thus the amount of data compression obtained will vary depending upon the characteristics of the data. You can find more in detail explanations about this topic in the following article: Tape Drive Data Compression Q & A
Can it I turn compression on or off in my tape drives? How?
Yes, but procedure may vary depending on your tape drive model and manufacturer. However, you can change most of the drive settings either with mt-st. In this wiki there's some mt commands to set compression that may be helpful for you: Hardware Compression (mt-st commands). Tools
Last updated