Can CTA work with IBM Ultrium -6 drives?

We have an IBM TS3500 tape robot with Ultrium-6 (LTO6) drives
that we want to use with a CTA. It used to work with Enstore
but hasn’t been used for a year now.
But apparently CTA does not support LTO6 tapes, since the LBP
format for them can be only reed-solomon when only CRC32
is supported in the CTA.
We didn’t find the option in the configuration to completely
disable the use of LBP, and cta-tape-label does not write
a new label, even on a blank tape since it always tries to write
a label with LBP CRC32 enabled.

Is there any way to install the CTA for us without changing the source
and rebuild?

Hello Vladimir,

we discussed about this today at the CTA operations meeting and we will continue the discussion on Friday at the CTA development meeting.

LBP support was added to CASTOR (CTA predecessor) tapeserverd (now cta-taped) in 2016 (following investigation in 2014). I was able to find the discussion here (not sure you have access to it):

Only CRC32 algorithm was implemented because it has a hardware support in CPU so there is no performance hit when using it.

We assumed that from that moment on, all drives will support it (there is a function that checks whether LBP is supported by the drive but not which algorithm). We did not consider implementing something backwards compatible.

That does not mean that it can not be done.

Would you be willing to contribute to implement an option in /etc/cta/cta-taped.conf file (deployed on every tape server) there LBP could be enabled or disabled? This would then be taken into account by the cta-taped as well as cta-tape-label.

Let us know what you think, as I stated above, we will re-discuss this again on Friday.


PS: Here another discussion about LBP : Problems reading Enstore tapes - #9 by ewv

Hi all,
looks like CTA partially dropped CASTOR features for LBP (disabling it).

I think it would be logically correct to auto-detect supported checksum algorithms if any before blindly set crc32c. I do not remember if this possible and why we did not implemented checks in this way.



thank you for your reply. Yes, indeed it looks like some LBP code logic was lost.

Would you be willing to contribute with a commit to cta-taped and cta-tape-label something like this:

if <LBP supported> AND <LBP algorithm = CRC32> then
    use LBP
    DO-NOT use LBP

I think this would cover your use case where you do not want to use LBP on LTO-6 tape drives at all. At the same time, I think it would have no effect on our setup with all our tapes LBP enabled.

Please let us know.

We will discuss this on Friday.

Best regards,


Hi, Vlado

Unfortunately I do not have any opportunity and time to code and test remotely for JINR where Vladimir from. From my point of view the easiest way for them to set compile time default useLbp to false until somehow mainstream CTA version will be changed if needed.


thanks for joining the discussion. We are looking for the easiest way to solve the problem.

Hi Vlado.
Thanks a lot for the explanation. We discuss the simplest way to solve the problem.

Hi Vladimir,
historically we went only for crc32c as reed solomon was going nowhere: crc32c is available as a cpu instruction and you get >10GB/s of streaming computation using 1 core.

non-LBP option was dropped entirely when moving to CTA as this is a key feature for various operations workflows and as allows to bypass additional verifications of all written data.

Maybe another thing you could try would be to write a small script to label your tape without LBP using dd (the snippet is still comment and was used CTA CI script before cta-tape-label was written).

This way when the tape is later mounted for write/read cta-taped should detect that the label was not written using LBP. I am then not sure what will happen to the tape: will cta-taped happily write on it going without LBP or complain and fail (same for read).

If you can give it a try on one tape (no guarantee).

Best regards,
Julien Leduc